YouTube

Got a YouTube account?

New: enable viewer-created translations and captions on your YouTube channel!

English subtitles

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

Get Embed Code
1 Language

Showing Revision 77 created 12/29/2018 by networkmess.

  1. 33C3 preroll music

  2. Herald: So… coming over to our next talk.
  3. Tonight, if you switch off
    your DECT phone, and
  4. if you’re full of different impressions
  5. – full of different impressions of this
    day you maybe want to watch TV.
  6. But it would be cool to have pay-TV
    – unencrypted pay-TV.
  7. So Chris Gerlinsky asks himself the same.
    And how to achieve unencrypted pay-TV
  8. – but the Hacker way. So Chris
    reverse-engineered nothing less
  9. than the signal and the encryption for
    a standard that remains unencrypted
  10. since the late 90s. Please welcome with an
    Anniversary Edition applause Chris Gerlinsky!
  11. applause
  12. Chris Gerlinsky: Hello everyone.
    My name is Chris Gerlinsky.
  13. I am a hacker from Canada and I’m here
    today to talk about how I cracked
  14. digital cable and satellite TV security.
    I studied an Access Control Platform (ACP)
  15. that’s widely used across Canada and the
    USA. It’s one of the two common platforms
  16. that’s used in cable TV,
    and it’s also used in satellite TV
  17. by one of the two Canadian satellite TV
    operators. As far as I know the system
  18. has remained secure since it was
    introduced in the 1990s and I was curious
  19. if I could understand the system based on
    the older set-top-boxes. Some of them
  20. are 15 years old – and they are still in
    use. So these devices haven’t received
  21. upgraded security hardware in that time and
    I started looking at how the system works.
  22. Before I get into the reverse engineering
    I’ll start with a brief description of how
  23. digital television is sent over satellite
    or cable. Satellite and cable digital TV
  24. are pretty similar for the most part. There
    are a variety of signal modulations used.
  25. The relevant ones here are QPSK at about
    27 MBit/s and 8PSK Turbo FEC at about
  26. 38 MBit/s for satellite and QAM256 at about
    38 MBit/s for cable. There is also an
  27. out-of-band channel used by cable
    which is QPSK modulated at 2 MBit/s.
  28. This out-of-band channel carries the
    subscription-management, program guide
  29. information, firmware upgrades, etc. And
    while you change channels and the cable
  30. box tunes to different frequencies this
    out-of-band channel remains tuned
  31. so that the box continuously receives the
    state, and no matter what TV channel you’re
  32. tuned to. In the satellite TV this type of
    data is included within the main transport
  33. stream (TS) instead of in a secondary
    out-of-band TS. The video is sent
  34. as MPEG2 or H.264 TS. This is a standard
    format for carrying video streams.
  35. So it can be played by any hardware video
    decoder or software decoder, e.g. VLC.
  36. And the encryption system used here is
    called DigiCipher 2 (DC2), which does not
  37. follow the DVB standards that are used
    in the rest of the world. The MPEG-TS
  38. is made out of packets of 188 bytes.
    Each packet has a PID. This is used
  39. to differentiate different types of data.
    PIDs range from 0 - 0x1FFF.
  40. Each PID carries an MPEG Packetized
    Elementary Stream (PES).
  41. That’s a video or audio stream.
    Or the PID may carry one or more
  42. Service Information Tables. The Service
    Information Tables have an 8-bit table ID
  43. and a length of up to 1024 bytes
    including a CRC32 for error detection
  44. and this table ID identifies the type of
    data that you can expect within the table.
  45. Table 0 is the Program Association Table,
    containing a list of programs carried
  46. in this TS and the PMT PID for each
    program. The Program Association Table
  47. is always on PID 0. Table 2 is the Program
    Map Table which contains the list of PES
  48. and the PID for each as well as an ECM
    PID. There is Program Map Table
  49. for each MPEG program or TV channel
    that’s found in the stream.
  50. The ECM PID is where ‘Entitlement Control
    Messages’ are sent containing information
  51. that’s used to generate the key that
    decrypts the Packetized Elementary
  52. Streams. This system uses two types of
    ECM. Table 40 I call ECM40, and Table 41
  53. I call ECM41. On PID1 there may be
    one or more conditional access tables,
  54. table ID No.1. These tables identify a PID
    that carries EMMs, ‘Entitlement Management
  55. Messages’. These messages are used to set
    access rates for individual set-top-boxes.
  56. The subscription information, like, what
    channels are available is carried inside
  57. of EMMs. This is a hardware interface to
    receive satellite data, a Genpix SkyWalker-1.
  58. The DC2 QPSK modulation isn’t widely
    supported in USB or PCI DVB-S devices.
  59. And the 8PSK Turbo FEC modulation support
    is even less common. And one of the devices
  60. that does support these signals is this
    Genpix device which is using a Broadcom
  61. BCM4500 demodulator. And it supports both
    the DC2-QPSK and the 8PSK modulations.
  62. It works well, the Linux drivers need to
    be re-compiled to include the support
  63. for these modes, and patches for this were
    published by updatelee. There’s a link
  64. on the slide. For cable there’s a variety
    of adapters supporting QAM256 de-modulation.
  65. I used a USB HVR 950Q tuner. Unfortunately,
    to tune the out-of-band channel is generally
  66. not supported by the off-the-shelf
    interfaces. Inside the cable box
  67. it’s handled within the integrated chip
    set. And for the ClearQAM consumer
  68. devices such as USB interfaces access to
    the out-of-band data isn’t actually required
  69. so they don’t include it inside of the
    hardware. This out-of-band data is used
  70. only for pay-TV services.
  71. With the satellite and cable interfaces
    DVBsnoop can be used to view a lot of
  72. information about the transport stream.
    It’s enough information to be
  73. quite overwhelming. So the trick to using
    it is being able to sift through the output
  74. for the relevant information. DVBsnoop
    also doesn’t recognize all of the
  75. DigiCipher 2 tables because it’s a non-
    standard system, and DVBsnoop is targeted
  76. towards the standard systems. So DVBsnoop
    may not be able to tell you everything
  77. about the transport stream but it was
    still a very useful tool for all the
  78. information that it can provide.
  79. DVBsnoop and most other tools and
    documentation are designed for the DVB
  80. standard or other recognized standards
    such as ATSC. DigiCipher cable
  81. and satellite systems use a lot of
    non-standard tables to carry
  82. the system information. For cable TV some
    of these tables are standardized by
  83. the document SCTE 65.
    There is no BAT or SDT
  84. as you’d expect in DVB. Instead there
    is a virtual channel table that maps
  85. the transport streams and programs the
    channel numbers. The electronic program
  86. guide is also not DVB standard. So you
    don’t even get the current and next
  87. program information in any
    kind of a standard format.
  88. Another cable TV adapter is the HDHomeRun
    Prime. This one is a network-connected
  89. three-tuner device with cable card
    support. The set-top-boxes I studied
  90. pre-date the cable cards. Although the
    newer boxes do use the cable cards,
  91. and they support the DigiCipher 2.
    But cable card support does also mean
  92. that this HDHomeRun Prime includes the
    tuner and QPSK demodulator for the
  93. out-of-band channel. So it is able to pass
    this data to the cable card, as necessary.
  94. However, even the HDHomeRun doesn’t
    make this out-of-band data available
  95. other than the cable card interface. So
    to access the demodulated out-of-band data
  96. I tapped in to the HDHomeRun Prime with
    a cable card inserted, and connected
  97. a logic analyzer to the Data and Clock
    signals. I wrote software using the
  98. Saleae SDK to capture the QPSK demodulated
    data. Then, in software, I performed
  99. de-interleaving, de-randomization,
    and the forward error correction.
  100. And the output is an MPEG transport
    stream. So using an HDHomeRun Prime
  101. connected to the logic analyzer, connected
    to the PC running the software
  102. the output finally is a 2Mbit/s transport
    stream. And this transport stream
  103. looks like a standard transport stream,
    and inside are the conditional access
  104. management messages, program guide
    information etc. Everything that was
  105. missing from the main
    QAM transport stream.
  106. Two bits in each packet will indicate if
    the packet is scrambled with the even key,
  107. odd key, or not scrambled at all.
    The key is changed at short intervals.
  108. DVB systems typically will change every
    5 .. 30 seconds. DC2 every 133 ms
  109. or 1 second. The key used for decryption
    alternates between even and odd.
  110. The odd key is in use while the even key
    is updated; and then the even key is
  111. in use while the odd key is updated.
    An encrypted transport stream is sent
  112. via the cable or satellite, and it’s passed
    through the descrambler in the ACP.
  113. And the result is a decrypted transport
    stream that is played by the MPEG decoder.
  114. The descrambler uses a Working Key.
    This is a 56-bit DES key that changes
  115. every 133ms, or in some cases they have it
    slowed down to changing every 1 second.
  116. This Working Key is generated by
    encrypting the frame count from ECM40
  117. packets with the Program Key. The Program
    Key, again DES, comes from the ECM41
  118. message, and is encrypted with the
    Category Key. The Program Key
  119. is unique to each channel, and it changes
    daily or for every pay-per-view event.
  120. The Category Key, also DES, is shared
    by all the set-top-boxes that authorize
  121. for any channel from this provider. The
    Category Key is sent to each set-top-box,
  122. individually, inside the EMM95 message.
    And this Category Key typically changes
  123. monthly, but many cable operators change
    keys much less frequently. Some of them
  124. are using the same key for years at
    a time. To decrypt the EMM, in order
  125. to get the Category Key Seed Keys are
    used. Each set-top-box has a set of
  126. 56 bit DES Seed Keys inside of
    battery-backed RAM. These are
  127. initialized during manufacturing. For the
    lifetime of the set-top-box these keys
  128. are used to secure EMMs. So this
    forms a chain from the Seed Keys,
  129. initialized during manufacturing and never
    changing, to the decryption of the MPEG
  130. transport stream.
  131. Inside the satellite
    set-top-box we can see the main
  132. components of the system. The signal
    enters the tuner and is passed
  133. through the demodulator which
    outputs a serial transport stream.
  134. This transport stream passes through
    the ACP – Access Control Processor –
  135. and is then sent to the MPEG decoder
    to output a video signal to the TV.
  136. A 68k microcontroller acts as the set-top
    box main controller. It communicates
  137. with the MPEG decoder as well as
    with the ACP via an SPI bus.
  138. A battery provides backup power to the
    ACP. So it will retain RAM contents
  139. even when the set-top-box is unplugged.
    There’s a TVpass slot near the power
  140. supply. This is an upgrade slot with
    a card edge connector to allow
  141. for security upgrades. The system
  142. stayed secure, so the TVpass slot was
    never used. And the newer set-top-boxes
  143. don’t actually include a TVpass slot
    inside. So at this point it seems
  144. quite unlikely that this TVpass card
    will ever actually be used.
  145. Inside the cable set-top-box… it’s
    very similar to a satellite set-top-box
  146. but the cable boxes tend to be more
    tightly integrated. The signal enters
  147. the tuner and passes through a Broadcom
    chip that handles demodulation.
  148. And the same chip will also handle MPEG
    decoding after the transport stream’s been
  149. decrypted by the ACP. A 68k microcontroller
    acts as the set-top-box’s main controller.
  150. Again, talking to the ACP via SPI.
    And a battery provides backup power
  151. to the ACP, and also to the non-volatile
    RAM used by the main controller.
  152. A TVpass slot is underneath the main
    board, it’s not visible in this photo.
  153. The cable set-top-boxes include a second
    tuner that’s used to receive
  154. the out-of-band data. This OOB tuner
    operates independently of the main tuner
  155. and on a separate frequency range. And
    it’s used to provide a transport stream
  156. containing the system information, with
    the program guide, firmware updates,
  157. EMMs etc.
  158. Here we see the ACP chip. It’s a 100-pin
    TQFP package. From the markings
  159. we can see it’s a custom System-On-Chip
    made for General Instrument Corp. (GIC).
  160. All the decryption is performed by the
    ACP, and all decryption keys are kept
  161. only within this chip. The newer set-top-
    boxes use newer versions of the ACP.
  162. I studied the original ACP chip
    that’s seen in this photo.
  163. As long as the set-top-boxes using this
    chip are actively used it remains
  164. a relevant target. Whether the newer ACPs
    include more advanced security features
  165. or if they exist only for cost-savings
    due to shrinking the die size
  166. I don’t really know.
  167. Some of the interesting pins on the ACP
    are labeled here. Pin 1 is marked
  168. at the top left corner of the chip.
    There’s an SPI slave controller
  169. on Pins 1 - 5, used for communication
    with the set-top-box main controller.
  170. There’s a battery backup pin that’s
    connected to a 3V battery to keep
  171. the RAM contents of the ACP intact
    at all times. There’s a serial transport
  172. stream input on pins 88 - 92 which
    receives the data from the demodulator.
  173. And there’s a serial transport stream
    output on pins 28 - 33 which sends
  174. the decrypted transport stream to the
    MPEG decoder to be output to the TV.
  175. At one point I had written software for
    an AVR32 device, not the one that’s
  176. shown here, that has a synchronous serial
    peripheral, that supports sending and
  177. receiving data at the 27 MBit/s rate of the
    transport stream. My AVR32 implementation
  178. turned out a bit ugly. But rather than
    cleaning up I was able to use it as it was.
  179. It had some limitations like only accepting
    64kB of data for replay logging.
  180. Which was just barely good enough for my
    studies. What the transport stream
  181. logging in-circuit digital mean was
  182. that the transport stream passes through
    the ACP with selected PIDs being decrypted.
  183. And then the output is the full transport
    stream but a selected program has been
  184. decrypted. The AVR32 logging interface
    had rather limited use for me.
  185. Later on when I did more thorough research
    I did so using an ACP that I’d removed from
  186. the box and I put on a breakout board.
    And then I could control the clock, and
  187. at that point it was much easier to use an
    XMEGA AVR platform to send and receive
  188. the transport stream through the ACP
    at a much slower bit rate. Shown here
  189. is the XMEGA platform I settled on using
  190. for SPI and also the transport stream
    interfacing. To honor the data
  191. passed between the set-top-box main
    controller and the ACP on the SPI bus
  192. I used the XMEGA development board. Two
    SPI ports acted as slave with Master Out -
  193. Slave In (MOSI) signal connected to 1 and
    Master In - Slave Out (MISO) signal
  194. connected to the Master Out - Slave In
    input of the second port. So from one port
  195. Bytes sent by the set-top-box
    controller are received.
  196. From the other port it receives
  197. bytes from the ACP. In case I want to talk
    directly to the ACP or the set-top-box
  198. main controller it’s only necessary to
    connect both the MOSI and MISO signals
  199. on one of the SPI interfaces. By holding
    the main controller in Reset my XMEGA
  200. was able to act as the SPI Master and then
    talk to the ACP. So this setup works for
  201. passively monitoring the SPI communications
    in the set-top-box and can also act as
  202. the SPI Master for interrogating the chip
    directly.
  203. By logging the SPI bus between
  204. the main controller and the ACP we see
    that information about the current access
  205. levels are sent from the ACP. The ACP
    also receives EMMs via the SPI bus.
  206. EMMs have been filtered by the Unit Address
    number, or the set-top-box serial number.
  207. So the ACP only receives messages
    that are intended for that specific unit.
  208. Command 04 includes the current Category
    Key epochs and Keyselects in use.
  209. Command 05 includes the Unit Address
    number. Command 13 returns the authorized
  210. Subscription tiers for this unit. Commands 7
    and 87 provide information about the channel
  211. being currently decrypted. Additionally,
    via the SPI interface the set-top-box
  212. main controller tells the ACP which PIDs
    to decrypt and which is the ECM PID.
  213. The ACP doesn’t send any keys on the bus,
    and it only receives Category Keys that
  214. are encrypted within EMMs via the SPI.
    So all of the really interesting data is
  215. contained within the ACP chip itself, and
    it’s never sent out on any kind of a bus.
  216. So next I started an invasive study of the
    chip – studying it under a microscope.
  217. And the cost of microscopes can range from
    hundreds of Dollars to tens of thousands
  218. of Dollars, or even higher for things like
    electron microscopes or other specialized
  219. equipment. I have a couple of microscopes
    that I use. This one is a Mitutoyo FS70
  220. microscope. These Mitutoyo are often used
    for microprobing, but you can also use it
  221. for other uses. For this project I didn’t
    do any microprobing but I used this
  222. microscope because it was what I had. For
    studying this kind of technology you could
  223. use even more basic equipment but,
    of course, if you have the higher-end
  224. equipment it’s a lot nicer to work with.
  225. Another microscope I use is the Zeiss
    Axiotron. This microscope is designed
  226. for inspecting wafers and has really good
    optical quality. I said that more basic
  227. equipment could be used and it’s true.
    But when you get into this kind of thing
  228. you might find yourself again and again
    investing in more equipment.
  229. I've owed $10.000 in this setup including
    the microscope and the camera and the
  230. scanning stage and other parts. To look at
    the chip under the microscope requires
  231. that the chip is de-capsulated.
    Fuming Nitric Acid is used for this.
  232. The chip is immersed in heated red Fuming
    Nitric Acid which reacts with the plastic
  233. packaging and removes it. The chip is then
    rinsed in acetone, and cleaned with
  234. isopropyl alcohol in an ultrasonic bath
    which leaves the die bare and clean.
  235. The Nitric Acid is quite aggressive,
    and it’s important to handle it carefully.
  236. But the process is really straight-forward.
    Most people probably wouldn’t want
  237. to do this in their home.
  238. So you should go out to the garage
    and use your fume hood there.
  239. After the decapsulation the bare
    chips are left with bonding wires attached
  240. to them. So these wires will be plucked
    off using tweezers to get them
  241. out of the way. Already in this photo we
    can see some of the larger structures
  242. on the chip. Half of it is covered with
    a metal plane, and the other half
  243. shows some kind of visible circuitry.
  244. This is an image of the chip under the
    microscope. It’s been stitched together
  245. from several smaller images,
    to give an overview of the chip.
  246. Looking at the decapsulated chip we see
    the bond pads around the outside,
  247. a metal plane covering the top part of the
    chip and wires on the bottom of the chip,
  248. the spaghetti logic running all ov er the
    place. With a couple of structures
  249. that look like they could be a type of
    memory. There’s a lot still hidden
  250. from us. To see more of the chip
    it will be necessary to delayer it.
  251. To delayer the chip I used hydrofluoric acid
    to perform a wet etch. I used the Whink
  252. Rust Stain Remover product. It’s available
    in hardware stores all over the USA.
  253. It’s a dilute HF solution that works
    really well for delayering ICs.
  254. I put a small amount of the Whink liquid in
    a beaker and heated it on the hot plate.
  255. Then I dropped the decapsulated die in.
    Using a pipette I agitated the liquid
  256. to disturb the bubbles that form on the
    surface of the chip. So the acid can
  257. actually chip more evenly. The etching
    result isn’t perfect. Some parts of the chip
  258. will be etched deeper than other parts.
    But I’ve gotten quite useful results using
  259. this technique. You really don’t wanna
    breathe in these fumes, so do this
  260. in a fume hood in your garage, also.
  261. After a short time immersed in the heated
    Whink solution the chip was rinsed and
  262. put back under the microscope.
    Now the top metal plane has been removed
  263. so we can see what’s below. There are
    some visual effects that we start to see
  264. in the photo from the etching being
    a little bit uneven. But overall
  265. the delayered chip looks quite good and
    able to start studying it. At the top left
  266. the tall rectangles are RAM. The four
    blocks at the top right are ROM.
  267. And then there’s logic that tie
    these into the logic area below.
  268. I was interested in finding how the bits
    were encoded in ROM. So I continued
  269. delayering the chip. This was another dip
    in the Whink – and another metal layer
  270. has been removed. Bits in the ROM
    were not visible yet so I continued
  271. the delayering process. At this point
    we’re starting to see more of the visual
  272. effects from the uneven etching but
    it’s still not too bad. After a third dip
  273. in the Whink more metal has been removed.
    At this point the delayering is becoming
  274. more and more uneven. We can see the
    ROM blocks have been half-etched
  275. to a lower layer while half of the upper
    layer is still remaining. The wet etching
  276. process can be quite difficult to perform
    completely consistently without adding
  277. additional steps such as polishing. And
    at the time I did this project I didn’t have
  278. the polisher available so I was relying
    only on the wet etch. Some of the areas
  279. of the ROM are now showing visible bits.
    The other areas haven’t been etched
  280. deeply enough. So I continued to etch
    further to try and get a clean ROM.
  281. We can see the ROM bits quite clearly now.
    They’re arranged in rows and columns, and
  282. in this image if a black dot is visible
    that indicates that the bit is a One.
  283. Image quality is important. The better the
    photographs the more consistently the bits
  284. will be visible. But it doesn’t have to be
    really perfect. You can do some image
  285. processing on it, you can even repeat the
    process on multiple chips, delayer them
  286. and photograph them, and at some point
    you’ll be able to have the entire ROM
  287. clean and consistently visible. With the
    visible bits exposed and photographs taken
  288. the bits can be extracted using a software
    image analysis tool. Or the bits could be
  289. extracted manually. The ROM here is 32 kB
    or over 260.000 bits. So manual extraction
  290. would be a bit labor-intensive but it
    isn’t impossible. A software tool is
  291. more efficient. So I wrote some software
    to analyze the images and identify
  292. the 1 and 0 bits. There are bits marked
    with a yellow box for 0 bits or a blue box
  293. for 1 bits. I use a software to analyze
    the image and then I can quickly review
  294. the results manually, and identify any
    errors that I can see. After extracting
  295. the bits from the photographs I have
    a binary version of the ROM data.
  296. This is a visual representation of the
    bits extracted from this piece of ROM.
  297. Little black boxes signify 1 bits,
    and the white boxes signify 0 bits.
  298. In this image I’ve overlayed the extracted
    bottom 13 rows of bits over the photograph.
  299. You can see some visual patterns inside
    this, also. And these visual patterns
  300. are a good indicator that this ROM
    is probably not scrambled.
  301. This image shows the end of the ROM where
    you can see a pattern covering most of
  302. the image due to a repeated pattern of
    filler bytes that occupy unused space
  303. at the end of the ROM. At the very end of
    ROM the pattern is interrupted. This is
  304. where the vectors table exists at the top
    end of memory indicating the reset address
  305. and the addresses of interrupt handlers.
    The ROM has unused space, the filler bytes
  306. at the end. And the vectors table
    address is 0xFFF6 through 0xFFFF.
  307. After extracting the bits and decoding them
    into bytes the hex dump can be studied.
  308. There is a “Copyright 1997 CHCC” ASCII
    string in ROM which is helpful to identify
  309. when the ROM has been decoded correctly.
    laughter
  310. If you can read the ASCII text then
    surely the bits are in the correct order.
  311. The decoding in this case was just a matter
    of organizing the bits into bytes, it’s quite
  312. straightforward, there was no scrambling
    or anything else that was complex.
  313. With the ROM contents extracted the
    software can be disassembled and analyzed.
  314. The first step was to identify the CPU
    architecture. Studying the binary dump
  315. it appeared to be an 8-bit CPU
    but wasn’t 8051 or 6805
  316. or any of the processor types I tried
    first. Eventually, I tried disassembling
  317. it 6502 and the code made sense. Later
    I had remembered that I had looked at
  318. a previous version of the Access
    Controller from the same manufacturer.
  319. Which was used in another system,
    VideoCipher 2+, an ancestor of DigiCipher.
  320. On the older chip was a Copyright notice
    from WDC who licenses the 6502 core IP.
  321. It was visible directly on the chip die
    under the microscope.
  322. So this would have been a great clue
    for the CPU architecture if I had actually
  323. noticed it earlier. For disassembly I used
    IDA. It supports 6502 and is of course
  324. a very powerful disassembler. In addition
    to disassembly I used 6502 simulation
  325. software to study the software in
    a virtual CPU. The simulation is really
  326. helpful when disassembling the software.
    It provides a lot of insight into what’s
  327. going on. Since 6502 is a very well-known
    architecture it was not at all difficult
  328. to find an existing simulator. Even free,
    with source code. The 6502 is used
  329. in 8-bit computers, like the Apple II,
    in Commodore 64. So there’s really
  330. a lot of enthusiasts and a great deal of
    information about this architecture.
  331. As I gained understanding of the System
    On Chip through disassembling the software
  332. I began adding some other features into
    the simulator to emulate some of the
  333. hardware peripherals that were found
    inside the ACP, the device itself.
  334. One of the first things I saw in the
    disassembly was that there are two
  335. operating modes. During startup values
    in RAM are checked. And if the ACP
  336. hasn’t been initialized it enters
    a personalization mode used during
  337. manufacturing to assign the Unit Address
    and Seed keys. In normal conditions,
  338. after the set-top-box has left the
    factory this personalization software
  339. is bypassed and the ACP will always run
    its main application. The next thing
  340. I found was the application wasn’t very
    simple. This 6502 actually runs
  341. a task switching operating system. Eight
    tasks are run supporting decryption
  342. of up to two channels at the same time.
    There are two tasks to handle processing
  343. of ECM40 messages and generation of the
    Working Keys used to decrypt the transport
  344. stream. And two tasks to handle processing
    of ECM41 messages to generate
  345. the Program Keys that are used to process
    the ECM40. One task for handling
  346. EMM processing. And there’s also a task to
    communicate with the TVpass interface
  347. for security upgrades. With another task
    to handle the messages that are coming in
  348. over the SPI interface. Since the ACP
    is a custom System On Chip
  349. there is no documentation available
    describing the hardware capabilities.
  350. So the disassembly was studied and the
    input/output registers had to be guessed
  351. based on the software usage. There’s an
    SPI slave peripheral for communication
  352. with the main controller. The SPI
    peripheral sends and receives data
  353. directly to RAM. And then a signal is set
    indicating that the transport has been
  354. completed. There’s a DES crypto peripheral;
  355. key, data and operating mode are set in
    registers. And when the decryption
  356. has been completed the result can be
    read from additional registers. There’s
  357. a transport stream descrambler. The Working
    Key is set in hardware registers.
  358. And the descrambler will then output the
    decrypted transport stream on the serial
  359. transport stream interface. There are PID
    filters set by the set-top-box main
  360. controller over the SPI bus. These filters
    select which video and audio streams
  361. to descramble and which ECM packets should
    be received by the ACP. The received ECMs
  362. are placed in RAM, and the 6502 is notified
    of a new ECM via a register bit.
  363. So at this point I’m starting to get an
    idea of how the system works.
  364. I have studied the MPEG transport stream
    and logged ECM and EMM data.
  365. I’ve logged the SPI bus, and understand
    messages between the set-top-box
  366. main controller and the ACP. I was able to
    extract the entire ROM contents optically.
  367. And I’ve disassembled the software and run
    it in simulation. There are some keys
  368. that are found in ROM. Fixed keys which
    never change and are used when a channel
  369. has a “free preview weekend” or something
    of the sort. Any set-top-box that has ever
  370. had any kind of authorization in the past
    is allowed to decrypt channels that are
  371. encrypted using the “fixed key” mode. So
    now the focus is on understanding the ECM
  372. and EMM algorithms within the ROM
    software. At this point I’m still missing
  373. some important information from the ACP.
    All the Seed Keys, Category Keys and
  374. Program Keys exist only within RAM.
    So to decrypt any of the channels
  375. not in free preview isn’t possible yet at
    this point. The ECM40 message
  376. is used to generate the Working Key, used
    to descramble the MPEG streams.
  377. There’s a Service ID, used to identify
    each channel, and a frame count
  378. that’s used with the Program Key
    to calculate the Working Key.
  379. The crypt mode identifies if the channels
    are operating unencrypted, with a fixed
  380. key, or with the normal secure keys
    which are typically used.
  381. The frame count is simply a 24 bit counter
    that increments each time the Working Key
  382. changes. There’s a byte I’ve labeled
    ‘Hardware’ that has one bit set in it.
  383. This selects a special decryption mode
    that I’ll come back to a little bit later.
  384. The ECM41 contains encrypted Program Key
    that’s needed to correctly decrypt the ECM40.
  385. There’s a Provider ID that indicates which
    TV operator subscribers this ECM should
  386. be processed by. And there’s the same
    Service ID that will be found within
  387. the ECM40 messages. The Category epoch
    identifies which Category Key is in use.
  388. There’s also information about how long
    this Program Key will be valid for.
  389. ECM41 contains one or more subscription
    tiers that must be found within
  390. the customer’s ACP to allow this message
    to be processed. The subscription tiers
  391. are written to the ACP when the EMM
    containing authorization details is received.
  392. There is, again, a hardware crypto select
    byte that I will get back to.
  393. This slide shows what a half of a second
    of ECM40 and ECM41 activity might
  394. look like. To be able to descramble the
    program the ACP must process a current
  395. ECM41 to get the Program Key and then
    process an ECM40 to get the Working Key.
  396. The Working Key is then used by the
    descrambler to decrypt MPEG stream.
  397. Until the ACP receives the ECM41 with the
    current key as well as an ECM40 with
  398. the frame count it’s not yet possible
    to decrypt the transport stream.
  399. The Working Keys have a short life time,
    only 133 ms. The series of ECMs shown here
  400. all would happen within a period of a half
    of a second.
  401. The EMMs are split into
  402. four parts. Each part contains a portion
    of the subscription information for this
  403. set-top-box. A Category Key is calculated
    from each of the four parts and the key
  404. that is calculated for each part has to
    match the others, or the EMM will be
  405. rejected, and all authorization in Category
    Key will be wiped from this ACP.
  406. When the first EMM, part Zero, is received
    the authorization data inside the ACP
  407. is reset and will be replaced with
    authorization data from the EMM.
  408. When the next part, part One, is received
    the existing authorization data within
  409. the ACP from part Zero is hashed along
    with the data in part One. If the result
  410. is correct then the authorization from
    part One is copied into the ACP
  411. alongside the existing data from part
    Zero. If the result is incorrect then
  412. the ACP’s authorization is erased. In this
    way the four EMM messages are linked
  413. together, and if anything is modified
    within any of the EMM messages
  414. the authorization will fail.
  415. This is an example of an EMM. Each of the
    four EMM parts contains some common
  416. information, like the Unit Address, and
    which Category epoch this EMM contains
  417. information for. The EMM can contain two
    Category Keys. One for the current epoch
  418. and also for the next so that when there’s
    the change of the Category Key the ACP
  419. already has the next key available.
    To decrypt the Category Key from the EMM
  420. the Seed Keys contained in the ACP are
    used. The Seed Keys are unique to each ACP
  421. and are assigned during manufacturing.
    EMMs are transmitted out-of-band
  422. for cable systems but they’re passed to
    the ACP in the same way as for satellite
  423. systems. So at the ACP level, there’s no
    difference between the satellite and
  424. the cable systems.
  425. At this point it should be possible to
    decrypt channels that are using
  426. a fixed-key mode. Analysis of the ROM
    has shown the algorithms used to process
  427. the ECMs and generate the Working Key.
  428. The fixed keys are known because they’re
    contained in ROM. There could have been
  429. some question about the possibility of
    bit errors from the optical ROM extraction
  430. process. But the fixed keys can be
    confirmed as correct because the ROM
  431. software performs a checksum of this
    256 byte area that contains the keys.
  432. Successfully running the checksum on
    the extracted ROM data indicates that
  433. the extracted keys seem to be correct.
    But when I attempted to decrypt
  434. a fixed-key channel there was
    a problem, it did not work.
  435. Whether it was a bug in my decryption
    implementation or something else
  436. was unclear. However, I had noticed the
    bit in ECM40 was set that causes a bit
  437. within the ACP hardware peripherals to be
    set. The purpose of the bit was unclear.
  438. But its address was suspiciously close to
    the transport stream descrambler key.
  439. So I started to suspect that there might
    be some encryption other than just
  440. standard DES.
  441. To be able to learn more about the ACP
    I started to look at glitchers.
  442. If I can succeed to glitch the chip I may
    be able to find a way to read and even
  443. write memory. And possibly a way to run
    my own software directly on the chip.
  444. This will allow me to control the hardware
    peripherals and be able to observe
  445. the chip’s operation under different
    conditions. Timing tests of the ACP
  446. suggest that the 6502 is running from an
    internal clock source. So this will allow
  447. a clock glitch attack. A VCC glitch makes
    sense, and with the age of this chip
  448. it seemed reasonable to expect that it
    would be susceptible to VCC glitches.
  449. The stronger protections against this
    type of attack are relatively recent.
  450. My glitcher design is quite simple. It’s
    based on an XMEGA development board
  451. and breadboard. I use the XMEGA to
    communicate with the ACP over SPI
  452. and to control the glitch. A 74xx series
    4053 analog switch is used to quickly
  453. switch the ACP VCC between two voltages,
    a normal operating voltage, and a lower
  454. glitch voltage. I use a bench top DC power
    supply and two outputs so I can easily
  455. adjust both the normal VCC and glitch VCC
    levels. Other parts on the breadboard
  456. are an oscillator to provide some clock
    inputs necessary for the ACP to operate
  457. and an inverter and NAND gate to cut out
    the clock during the time of the glitch.
  458. To simplify the test setup as much as
    possible the ACP was removed from
  459. the set-top-box and soldered to
    a break-out board. In this process
  460. the battery-backed RAM was disconnected
    and all the keys were lost.
  461. But for the purpose of developing a
    working glitch this was okay. The simple,
  462. breadboard-based glitcher is quite
    flexible. The breadboard can be modified
  463. to test different ideas, and reconfigured
    quickly. More complex and advanced
  464. glitcher wasn’t necessary.
  465. To test the glitcher, to find out if it
    will work and what voltage levels
  466. are successful we can send a command
    to the ACP, then glitch, and then see
  467. the response from the ACP. The general
    strategy is to lower the voltage just
  468. to the point where the chip sometimes
    resets due to the glitch.
  469. By adjusting voltage levels and glitch
    length and timing when the glitch will end
  470. I succeeded to cause ACP responses to be
    altered. The checksum on SPI packets
  471. is very convenient. When unusual data is
    received from the ACP chip with a valid
  472. checksum it’s a pretty good sign that the
    glitch caused a temporary fault within
  473. the CPU, but their normal operation was
    resumed. Depending when the glitch
  474. is delivered different effects are seen.
    We can see that generally, as the glitches
  475. moved later, it’s the later bytes of the
    response packets that change.
  476. So at this point it looks like the glitcher
    works, and is able to cause a pretty fault.
  477. Since I had an effectve glitch I took
    the circuit from the breadboard
  478. and etched a simple PCB that I could plug
    directly on the XMEGA development board.
  479. This performs exactly the same function
    as the breadboard glitcher but
  480. I’m a bit less likely to accidently unplug
    a wire from the breadboard and
  481. have to repair things. The circuit was
    simple enough that I could create
  482. a one-sided PCB, so it was very easy
    for myself to etch at home.
  483. Now my goal is to have the ACP execute
    the code of my choice. Because the 6502
  484. is a von-Neumann architecture all code and
    data memories share the same address space.
  485. From software disassembly I saw that there
    didn't appear to be any paging or MMU
  486. features. The software in ROM is fully
    self-contained. There is no EEPROM
  487. and RAM is never used to hold executable
    code. So there aren’t jumps into
  488. these areas to exploit and, in fact, it
    wasn’t clear if there’s anything preventing
  489. code execution outside of ROM. I decided to
    take a chance and test if RAM is executable.
  490. So I sent a message via SPI, knowing that
    this message will be stored in RAM.
  491. The message contained 6502 executable code
    that will copy itself to an unused area
  492. of RAM, execute from this area and send
    an ACK indicating it was successful.
  493. Because I studied the use of the SPI
    interface and the ROM code I’m able
  494. to create this executable payload that
    will continue to receive commands via SPI
  495. after it’s taken control over the ACP.
  496. To try to maximize chances of success
    I looked through the ROM code for
  497. multi-byte instructions, which, if broken
    up, would have contained within them
  498. a jump op code with a destination that
    should lead to where my executable
  499. payload was placed at RAM. Since the ACP
    has a single address space this gives
  500. a lot of opportunities for glitching to
    cause execution to reach the payload.
  501. There are multiple scenarios possible in
    addition to my selected glitch target.
  502. Stack corruption is a possibility, and
    really any abnormal program flow has
  503. some possibility that it could eventually
    land in my code. The von-Neumann
  504. architecture, without strong memory
    management, is a very fertile ground
  505. for glitching. Anything in RAM
    potentially could be executed.
  506. So at this point there are several
    uncertainties, but so far nothing
  507. totally rules out the possibility of
    success. The ACP operates from
  508. an internal clock source. And the
    interrupt-driven task switching
  509. does add some further timing uncertainty.
    So I’ll send the code payload,
  510. delay, then glitch, and see the result.
    When it’s unsuccessful I change
  511. the delay and I try again.
    I tried to aim for the instruction
  512. that I’ve identified as possibly
    corruptible into a jump.
  513. But there are a lot of unknowns, so,
    really, the processor is like fishing:
  514. throw the line and hope. I have
    a target but no way to know if I can
  515. hit it, or if it will have
    the expected result.
  516. But sometimes fishing is good.
    Relatively quickly the ACP returns
  517. an ACK indicating a successful glitch. The
    first successful glitch took some hours
  518. to find. And then, after this it was
    possible to make it work repeatedly
  519. in a matter of minutes or even seconds.
    So now I have my code executing
  520. in RAM, I’m able to send the ACP
    additional pieces of code to be executed.
  521. This allows me to read any memory address,
    write any memory address, and perform
  522. any other operations
    possible with the 6502.
  523. I wrote a simple application to perform
    glitch surges, and then to interact
  524. with the code payload backdoor installed
    in RAM. And this program allows me
  525. to enter an address and length and have
    data returned. Or write memory etc.
  526. There’s also support for setting the key
    and data, and performing DES encrypt
  527. or decrypt using the DES hardware that’s
    inside the ACP. A few things I noticed
  528. at this point: there’s a 2 kB area of ROM
    that, if I attempted to read it, caused
  529. the chip to reset. This area of ROM
    contains the personalization routines
  530. that are never normally used
    after the device leaves the factory.
  531. There’s also protection against modifying
    the Seed Keys in RAM. Trying to store
  532. a value in these memory locations
    appeared to do nothing.
  533. There are specific addresses within RAM
    that can’t be read or the chip will lock up.
  534. These are clever traps put in place
    as a security measure. The 7-byte
  535. 56 bit keys stored in RAM stride all these
    dead addresses. So a potential exploit
  536. that could cause a linear dump of memory
    will be stopped before a complete key
  537. is ever read. When the chip is reset it
    means having to glitch it again, because
  538. my code payload exists only in RAM, and
    there is no way to hook in a permanent
  539. backdoor.
  540. Since we can execute code on the ACP the
    receiver responds, we can read the ROM
  541. to have its contents without any of the
    errors that were introduced during
  542. the optical extraction process. Comparing
    the results of the optical ROM extraction
  543. with the proper dump we can see how many
    errors were in the optical extraction.
  544. Overall the optical extraction was quite
    good. It was, after all, good enough
  545. to understand the software and get us to
    this point. There is only one byte with
  546. more than a single incorrectly flipped
    bit. Many of the errors that existed
  547. were quite obvious from disassembling the
    software. If an instruction is out of place
  548. but flipping a single bit would make it
    sensible then it was probably a bit error.
  549. I didn’t keep detailed records but I think
    I probably caught about half of the ROM
  550. errors during the disassembly process
    before I started glitching.
  551. The interesting keys in the ACP are all
    stored in RAM only. This includes
  552. Working/Program/Category and Seed Keys.
    The RAM is battery-backed.
  553. If the Seed Keys are ever lost from RAM
    this ACP can no longer process EMMs
  554. and so is useless. It’s possible to glitch
    the ACP and read memory, but the glitcher
  555. works on an ACP removed from their
    set-top-box. When the ACP is in-circuit
  556. the connections to other components and
    16 VCC-connected pins pose the problem.
  557. To glitch the ACP in-circuit we’ll require
    some modifications to the set-top-box
  558. disconnecting the ACP from other parts.
    Or, another alternative is to remove
  559. the ACP from the set-top-box and place it
    on a breakout board without loosing
  560. the battery power and wiping RAM. Rather
    than modify the set-top-box, where each
  561. of several different models would have
    required unique modifications I decided
  562. to try to remove the ACP with the battery
    still attached. The plan is to carefully
  563. lift the Battery and Ground pins while the
    set-top-box is powered on providing VCC.
  564. I use a small tool I made from a razorblade
    using a Dremel tool, then attached
  565. the handle of a screw driver. This tool
    can be wedged under a pin, then with
  566. some hot air the solder will melt and
    a single pin can be lifted straight up
  567. without damaging any of the other pins.
  568. With the pins lifted an external battery
    can be attached.
  569. After attaching an external battery…
  570. applause
  571. After attaching an external battery the
    set-top-box is unplugged, and the ACP
  572. can be removed from the set-top.box using
    hot air. The ACP can be removed from
  573. the set-top-box, glitched, and can even be
    placed back in the set-top-box, if desired.
  574. To do this I just use hot air and a lot of
    flux. Additionally, once the interesting
  575. keys have been extracted it may not even
    be necessary to replace the ACP
  576. in the set-top-box. The ACP is now placed
    on a breakout board and connected
  577. with the glitcher. Not all the pins need
    to be connected. Only a handful of pins
  578. are actually used by the glitcher. You can
    also see at this point the glitcher is
  579. in a project box. The aesthetics greatly
    improved since the breadboard-based
  580. glitcher. But the functionality is
    identical. The timing of ACP responses
  581. is different on a chip with valid RAM
    compared to the previous chips
  582. that I had glitched before. I didn’t
    confirm whether the cause of the timing
  583. difference was due to a different
    oscillator configuration or just
  584. a different software path. But by
    adjusting the timing of the glitches
  585. the executable code payload runs as it did
    on the previous chips. So now we can read
  586. the RAM contents of a valid ACP, including
    the Category Keys, if the set-top-box had
  587. current authorization, as well as the Seed
    Keys that are used by this ACP to decrypt
  588. EMMs. With a valid Category Key ECMs can
    be decrypted, and a cracked Working Key
  589. can be calculated for any channel. Now,
    with the capability of running my own code
  590. of the ACP it’s time to look at the
    transport stream descrambling.
  591. There’s a hardware register bit that
    is set or cleared, based on a byte
  592. in the ECM40. When this bit is cleared
    standard DES decryption is used.
  593. When the bit is set the transport stream
    descrambler acts differently. Additionally,
  594. there’s an 8-bit hardware register in the
    DES peripheral area. When it’s Zero
  595. the peripheral operates the standard DES.
    For any other value the peripheral acts
  596. differently. At this point I started to
    think I might be looking at doing
  597. a Gate-level reverse engineering of the
    chip to understand this functionality.
  598. The chip is using technology that’s older.
    So reverse-engineering should be feasible.
  599. But, if possible, I’d like to avoid all
    this extra work. It would be quite
  600. time consuming, and might give imperfect
    results, similar to the optical ROM
  601. extraction. So I started with trying to
    characterize descrambling modes.
  602. The transport stream packet is made up
    of a 4-byte header and 23 blocks of
  603. 8 bytes each. The DES operates
    on these 8 byte (64 bit) blocks.
  604. By flipping one bit in encrypted input ECB,
    CBC or OFB modes can be differentiated.
  605. Flipping one bit causes an 8-byte block
    to be corrupted, and the corresponding bit
  606. in the following block to be flipped.
    This indicates CBC mode is in use.
  607. Timing of the input compared to the
    decrypted output was measured with
  608. the descrambler and standard DES,
    and in the custom hardware mode.
  609. No timing difference was seen. This
    suggests the internal properties of DES
  610. haven't changed. Which makes sense
    because the decryption has to be done
  611. in realtime. So this suggests that crypto
    customizations are not affecting
  612. some DES internals like the number of
    rounds. Also by using ACP as a decryption
  613. oracle I determined that the customization
    affects each of the 23 blocks of the
  614. transport stream differently. Next
    I tested the software using DES ‘weak keys’.
  615. These are certain keys not recommended
    for use with DES because their properties
  616. weaken the cryptographic strength.
    A key of all Zero or all One bits
  617. will cause DES decryption and encryption
    to be identical. That is running the same
  618. data through Encrypt or Decrypt will give
    the same result. I can test this on an ACP
  619. configured for standard DES decryption
    and see the expected ‘weak key’ behavior.
  620. When tested with the descrambler in custom
    mode the ‘weak key’ behaviour changes.
  621. Using a key of all Zero or all One didn’t
    produce the same results in Encrypt
  622. and Decrypt modes. Looking at the other
    hardware register, testing the DES
  623. peripheral with different values in the
    8-bit register, and using ‘weak keys’,
  624. shows that the standard DES ‘weak key’
    behaviour still exists. So my hunch
  625. at this point is that one customization
    affects the key, and the other customization
  626. affects the data. At this point I can’t be
    certain, but I have a good feeling about
  627. the theory, so I continue to investigate.
  628. Based on the idea that the hardware
    customization affects only the key
  629. and decryption is static I thought the
    simplest customization will be an XOR
  630. mask that’s applied to the key before it’s
    used for DES decryption. XOR requires
  631. only a single gate in series of the DES
    engine so it fits the requirements of
  632. fast and very simple implement in
    hardware. A change of even a single bit
  633. in the key could cause the observed
    effects. Flipping more than 28 bits
  634. will be pointless. That’s the same as
    inverting a key and flipping fewer bits.
  635. More flipped bits means more gates
    necessary for the customization, so
  636. it makes sense to flip a minimal number
    of bits. So I wrote this wonderful FOR loop,
  637. nested 16 levels deep, to test decryption
    results after flipping one bit of the key,
  638. then flipping two bits, then three bits
    etc. of the 16 bits. To test all the
  639. possible keys will take a long time. But
    if only a few bits are flipped then it
  640. might be possible to run it in a shorter
    period of time. And promising results
  641. did come quickly. It turns out the theory
    held up. And some of the blocks have
  642. as few as three bits flipped. This takes
    only seconds for the software to identify.
  643. After verifying that these work for XOR
    masks, for these logs the software then
  644. was left running to find all 23 masks.
  645. The simple brute-force method worked,
    it ran for a couple of days to identify
  646. all the 23 masks. By more carefully
    analyzing which bits were being flipped
  647. in the early results a pattern can
    actually be found. So the search could
  648. have been more limited. Using this
    technique the software cracker could have
  649. completed it in under a second.
  650. After successfully solving the first
    hardware customization the theory
  651. that the second customization is
    a Data XOR looks promising. It makes sense
  652. that one or more XOR gate is enabled by
    each bit of the 8-bit hardware register.
  653. Using the ACP as a decryption oracle
    a known key in Data were decrypted
  654. with all values of the 8-bit register.
    Software attack of this function
  655. was successful, and 255 XOR masks were
    identified, behavior matching what was
  656. expected. I haven’t actually seen this
    customization in actual use. Presumably,
  657. they’re saving it to be used as
    a countermeasure against pirate devices
  658. when necessary. But it hasn’t been
    necessary since the system never had
  659. a security breach.
  660. laughs
    applause
  661. In order to implement a Softcam, a software
    implementation of the descrambler,
  662. a few cryptographic details need to be
    identified. But at this point I have
  663. all the tools to do so. The initialization
    vector used for CBC mode can be found
  664. through simple XOR. And the handling of
    short blocks – those less than the
  665. 64 bit DES block size can be identified
    likewise. With all these details
  666. a software implementation of the
    EMM decryption of Category Key and
  667. ECM decryption of Program Key and Working
    Keys can be made and the transport stream
  668. descrambler can also be implemented in
    software. The rapid key changes and the
  669. use of DES with h/w customizations makes
    it a bit different to implement, compared
  670. to a Softcam for typical DVB systems,
    but overall the concept is the same.
  671. And now it’s all working! I was able to
    test it, and it’s fully working on both
  672. the satellite and cable systems. This
    is a screen that’s broadcast before
  673. a pay-per-view event goes live. The
    pay-per-view, like all other channels,
  674. can be decrypted with the Softcam using
    the algorithms learned in these keys that
  675. were extracted. With the ECM and EMM
    algorithms and Seed Keys for a set-top-box
  676. with any level of authorization the
    Category Key can be decrypted
  677. and then used to decrypt any and all
    of the channels that are broadcast
  678. by this provider.
  679. applause
  680. A few of the weaknesses that I identified
    in this system were that the ACP I studied
  681. is relatively old technology, almost
    20 years old. So this makes it a lot
  682. easier for invasive analysis today
    than one that was brand new.
  683. The TQFP100 package is quite easy to deal
    with compared to modern alternatives.
  684. The chip is susceptible to voltage
    glitching. It’s a van-Neumann architecture
  685. without strong MMU protection preventing
    code to be executed from RAM.
  686. They didn’t leave any possibility for code
    update or dynamic code execution
  687. for countermeasure purposes. The software
    for the ACP is contained entirely in ROM
  688. with no mechanism for software updates in
    the field. The hardware customizations
  689. to the crypto were quite simple and
    required no reverse-engineering
  690. of the chip logic. I was basically able to
    guess the hardware customizations.
  691. I was impressed with the design of the
    system. It was actually stronger than
  692. I anticipated when I started the project.
    All the key handling and decryption
  693. is contained within a single chip which
    makes it impossible to do key sharing
  694. that’s being done with some of the
    smartcard systems. The fast Working Key
  695. change interval – only a 133 ms – also
    makes key sharing more difficult.
  696. And the short lifetime of the key makes
    cracking it in realtime quite unrealistic.
  697. The lack of code in any rewritable memory
    means there’s nowhere to write code for
  698. a permanent backdoor to disable the
    access controls. I listed this also as
  699. a weakness but in fact this is a strength
    as it limits the attacker’s capability
  700. to install any kind of persistent
    backdoor. The chip operates
  701. on an internal clock eliminating clock
    glitch attack and making timing
  702. a voltage glitch a lot more difficult.
    These dead addresses in the middle
  703. of DES keys prevent linear readout of
    keys. If one were to cause a loop reading
  704. data to go out of bounds and reach the
    area of RAM where keys are stored
  705. the chip will reset before an entire key
    is read. After the first couple of bytes
  706. a dead address will be accessed that
    causes the chip to reset.
  707. The personalization ROM appears to be
    inaccessible so it can’t easily be used
  708. to modify the keys and Unit Address
    within the ACP. The Seed Keys
  709. aren’t easily changed so the
    set-top-boxes can’t easily be cloned.
  710. The keys exist only in RAM so you have to
    maintain a battery backup at all times.
  711. This rules out a lot of invasive attacks
    to retrieve the keys. And there are
  712. no group keys used for EMMs. All the
    unit addressing is to individual units.
  713. So you have to pull keys from an actively
    subscribed box in order to get active keys.
  714. That said if you have keys from a box
    that is subscribed to any channel
  715. you’ll receive an EMM containing the
    Category Key which is capable of
  716. decrypting all channels. So you don’t need
    to have a subscription to all channels
  717. you want to decrypt as long as you’re
    authorized for at least one channel
  718. on the system.
  719. The software is generally well designed
    and written. I didn’t notice any glaring
  720. bugs within it. Although DES is used the
    EMM decryption requires using three
  721. DES keys, and multiple rounds are
    performed when decrypting EMM and ECMs.
  722. So this part isn’t as simple as
    cracking a single 56-bit key.
  723. Brute-forcing, starting from the encrypted
    transport stream requires cracking
  724. Working Key, then Program Key,
    then Category Key and, finally,
  725. the three Seed Keys.
  726. You might wonder how many set-top-boxes
    it took for me to complete this project!
  727. laughter and applause
  728. The truth is I only needed the one…
    …truck load!
  729. laughter
  730. Some of the boxes had different versions
    of the ACP chip. Many of the boxes had
  731. different PCB layouts. So it was
    interesting to be able to look at
  732. a variety of boxes. The cost of used set
    top boxes was low, ca. $20. And for
  733. this research I was focusing on the signal
    security and didn’t need the PVR
  734. functionality or any of the advanced
    features from the expensive set-top-boxes.
  735. So at this point I have a brief anti-piracy
    message: I don’t recommend you pirate
  736. cable or satellite TV. There is never
    anything good on. It doesn’t matter
  737. how many channels you can decrypt.
    Believe me – I looked!
  738. It’s not worth the effort!
  739. laughter and applause
  740. Herald: Do we have questions
    from the room?
  741. Questions – please use the microphones.
  742. I know there is one question
    from the interwebs.
  743. Signal Angel: Okay, hello.
    This is working? Good.
  744. So the first question from the internet
    is: how many chips did you destroy
  745. or make unusable, and how did you
    get all those set-top-boxes?
  746. Chris: Because the cost of the used
    set-top-boxes was quite low I wasn’t
  747. afraid to destroy several chips in the
    process. It didn’t take as many
  748. as I would have expected in the beginning.
    Two or three chips were used for the
  749. decapsulation and the delayering process.
    I ended up extracting the ROM
  750. from a single chip. And then, when
    it came to glitching, there were
  751. three or four chips that I removed and
    erased the RAM from to develop the glitch.
  752. When I finally got to the point where
    I was extracting keys from a valid chip
  753. the very first chip that I tried worked.
    So there were few casualties involved!
  754. Herald: Thank you! Microphone 3
    was the first one, please!
  755. Mic3: How many years
    did this project take you?
  756. Chris: I would work for a few weeks at
    a time and then get burned out and
  757. take a break, and then come back to it.
    Most of the work for the project
  758. was completed over about a 2-year period.
  759. Herald: Thank you. And…
    Microphone 2, please!
  760. Mic2: Hi, thank you for a great
    lecture. How comes that
  761. the content decryption was DES and
    not a DVB-CSA because we're used
  762. that content is encrypted
    with DVB-CSA in these DVB systems.
  763. Chris: In North America we
    don’t believe in standards!
  764. laughter
  765. Mic2: Thanks!
  766. Chris: The timing was also a part of it.
    The system was being developed
  767. at the same time as DVB was being
    standardized. So General Instrument
  768. rather than going along with the Standards
    Group and waiting for the standardization
  769. they went with DES, directly.
  770. Herald: Thank you. And another one
    from Cyber-Cyber… space!
  771. Signal Angel: Okay. Another question from
    the internet is: you have all this fancy
  772. like lab equipment stuff. How were you
    able to afford that?
  773. Chris: I’ve been quite interested in this
    for a long time. So I’ve collected
  774. this equipment over a period of years.
    And I do some work, professionally,
  775. in reverse-engineering. So whenever
    possible I use our client’s money
  776. to buy another piece of
    equipment for the lab.
  777. To do this actual work, though, you could
    even use more basic equipment
  778. because of the age of the chip. You could
    use a microscope that you could find
  779. easily for $1.000 .. $2.000 or even less
    and have quite good results.
  780. So it’s not trivial but it’s not a huge
    amount of money for a lab equipment!
  781. Herald: Not that huge!
    Microphone 2, please!
  782. Mic2: What do you do for a living
    besides reverse-engineering?
  783. Chris: Reverse-engineering!
    laughs
  784. Herald: Thank you. And the internet!
    Again.
  785. Signal Angel: Okay. Next question is…
    somebody wants to know how…
  786. …which software did you use for the
    automated image analyzing, and
  787. is it available somewhere?
  788. Chris: Like everybody else that I’ve known
    that’s done optical ROM extraction
  789. I developed it myself. Everybody seems
    to develop their own tools from scratch
  790. for that. The image processing I used was
    really quite simple. So it didn’t take
  791. a lot of advanced algorithms or anything
    like that. So I’m using some software
  792. I developed personally, and
    it hasn’t been released.
  793. Herald: Microphone 2, please!
  794. Mic2: And how did you keep the boxes
    subscribed? So did you call them
  795. every week “Oh, my box broke down,
    I got another one”, or how is this done?
  796. Chris: For most of the research that
    I did I didn’t need an active box. I did
  797. all the research just on previously
    activated boxes that had lost their
  798. authorization. And by the time I had the
    process figured out, that I knew how
  799. to extract keys from a valid box
    I only needed the one box.
  800. Mic2: And had you heard back
    from the cable provider about this?
  801. Chris: No.
  802. Herald: Okay, thank you.
    Microphone 3, please!
  803. Mic3: Hello, thanks very much for the
    lecture and ‘well done’ on all the work!
  804. My question is: how does the glitching
    work, the glitching attack?
  805. Chris: The glitcher was quite simple.
    I drop the voltage for a very brief period
  806. of time. And it’s enough time that it
    causes at least one instruction to
  807. not execute properly. But it’s too short
    of a time to cause the chip to reset.
  808. So essentially I’m corrupting one
    instruction. It is for the specific target
  809. that I hit that led to my code in RAM.
    I’m not actually sure. I found that
  810. if I glitch it this time then the code
    ends up executing my code –
  811. good enough for me!
  812. Herald: Okay. Thank you, Chris!
    Please, dear audience,
  813. give an Anniversary Edition
    applause to Chris Gerlinsky!
  814. Anniversary Edition applause
  815. postroll music
  816. subtitles created by c3subtitles.de
    in the year 2018