CableCard Internals
CableCard Internals

The image to the left is a Motorola CableCard. Doesn’t that sentence sound familiar? I’ve written previously about the subject.

Click on the image for a much higher 9875 x 16046 detailed view.

I’m still scratching my head and trying to find a perfect solution for digitally scanning any arbitrary PCB, regardless of placement or onboard components. The fact is, I haven’t yet found a good all-round solution.

The CableCard PCB here was scanned using a flatbed scanner at 6" x 6" at 4800dpi. Each side took 4 minutes to scan. The resulting images were 19200 x 19200 at 1.1GB each. Larger than I’d first thought, although disk and memory is cheap. The more pixel detail I get - the happier I am.

As with any project, the top and bottom layers had to be brought into Photoshop and manually aligned and inverted using the same technique I’ve written about before. This allows me to quickly flip the board over virtually in-order to follow PCB traces without distracting my eyes.

If you’re interested in the pinouts for the device, and the protocol, you should checkout this slightly older CableLabs CableCARD Interface 2.0 Specification document. The newer versions of this document don’t bring much to the discussion, they’re not worth chasing down for this article.

Here’s the same quality scan of the bottom layer. Not a lot going on here.

Before I go any further I need to point out a few things. I purchased this Motorola MediaCipher card from eBay a few years ago, along with a few others. Over the years I’ve collected a series of CableCard and I’ll probably open up another brand for comparison in the future. I haven’t rented it and I have no idea when the card was last used.

My goal isn’t to circumvent security or knowingly violate any laws.

Ass covering said… You should reaslize that CableCards are going cheap on eBay, $10 or so.

In terms of receiving TV signals they’re useless to me as my MSO (Cablevision / Optimum) uses Cisco/NDS based cards. That being said, they’re still useful for doing teardowns and testing interaction with CableCard receivers, when no RF connected or when monitoring the message control bus.

A couple of immediate observersations from both PCB layers

All the major PCB traces are buried between layers running to and from the BGA packages, to be expected and infact required for CableLabs device certification. I didn’t expect to find a completely exposed bus to the flash or SDRAM.

Sidenote: The CableLabs cert requirement specifically says (paraphrase):

The device should be tamper resistent and thus prevent access to restricted keying material. […] prevent access from any person using readily available and inexpensive debugging equipment.

A battery! - Perhaps keeping the SDRAM alive while the device is not connected to a host?

I continue to find small but annoying issues while using a scanner on PCBs.

Have you noticed the shadow next to the package on this image to the left. I’m reasonably sure I could clean that up in Photoshop - still - its a hassle. I also find that most PCBs don’t sit flat on the scanner glass, which causes some minor off-angle scanning issues including the inability to perfectly align. I get close, close enough, but I’d like to align a little tighter than what my scanner allows. This fluctuation tends to skew the pcb traces by a millimeter between layers.

All things considered, the effort it took to scan and manually align both layers was probably 30 minutes, still trivial by any measure.

I started adding layers in Photoshop for comments as well as sketching out the major control interfaces looking for any obvious interconnects. I didn’t find much of interest but I will point out two or three interesting things.

Firstly this, the cablecard has pins 6, 7, 8 connected from the 68-pin header directly to the SOC.

These pins are unused in the specification and would not expect to be driven by any ‘in spec’ CableCard device. Either designers want to screw with anyone looking at the PCB, or more likely, its some kind of manufacturing or diagnostic interface which needs a custom test device to interact with it.

Looking at the PCB, the ground plane doesn’t flood the entire PCB. Its possible to see buried traces in some parts of the design using a bright light source.

This image is much poorer than I’d like but it demonstartes a useful technique.

I used a flashlight on the underside of the PCB then took the image using an iPhone looking through the eye-piece of my optical microscope. You can clearly see the edge of the battery and a few traces. Some of those traces are actually visible on the bottom of the PCB (not buried), but when I repeat the same test on other parts of the PCB I can clearly see a few buried traces.

I should pop a camera into the Microscope, a future project.

The overall effect is much more interesting when you’re just examining the ground plane edges directly through the microscope, and no iPhone is involved.

Here’s the cablecard message/control bus, where the host device sends messages to/from the CableCard to request service information, query conditional access states, select tv channels for processing, as defined in the CCIF 2.0 document mentioned earlier. Its a lot like a SPI bus in terms of its electrical activity, along with a couple of adjustments as covered by the CCIF 2.0 spec above.

During debugging I inserted the card into a working HDHomeRun and looked at the control lines using an oscilloscopee. The Host is communicating with the card, its responding and alive, communicating at a rate of 6.75MHz. It would be trivial to tap some debug wiring onto the resisters and hook all four signals into a logic analyzer for inspection. The control bus is a very close relative to SPI, easy to inspect.

Warning: Even if you wanted to, trying to modify the messages to/from the host and CableCard would not breach any security. Any important messages are securely signed between the host and CableCard to prevent man-in-the-middle tampering. That being said, reading the bus can be useful when debugging behavioural problems.

On other pins I see the 27MHz transport in/out clocksi, a pair of 8bit parallel TS data buses - so everything appears to be alive in the card.

The test pads are all active. I only measure clocks and gpios or various voltages. I don’t see any control messages, although I didn’t try measuring when exercising the flash or booting the device). Given enough time and patience, all the test pads should be monitored during a series of power up, boot and reset exercises.

Sidenote: I once built a small project based around a Cypress FX2 Microcontroller and a PCMCIA extension board in-order to intercept and record cablecard control messages between the host and CableCard directly to a PC. I plan to write about this in a future article, but in the meantime here’s a quick teaser.

The cablecard inserts into the PCM extender / adapter upside down, the FX2 microcontroller monitoring (read only) the communication between card and host.

The PCB has two rows of 13 test points. Similar to the other named test points, I saw nothing other than clocks, voltages and possible GPIOs on these. But, like the test pads mentioned previously, I didn’t try measuring when exercising the flash or booting the device).

Given enough time and patience, a lot had be learned about this physical cablecard design simply by repeatidly power cycling the device while monitoring the various test points.

If I was trying to obtain the contents of the flash I’d probably remove the solder mask on the VIAs in and around the flash (grind it off) and look for activity during boot. Or, Hot air the flash BGA, remove it off the PCB and insert it into a reader.

or… ask someone on a Comcast, TWC or FIOS plant to run a Linux app for me, so I can gather the firmware directly from their plant. Some of the MSOs broadcast set-top-box and CableCard firmware using regular QAM channels, while others use the OOB. This is an easy and first approach I’d take - if I wanted their firmware.

Questions

I’m not too sure what the Freescale CPU is. I’ve googled a little and it looks like a custom CPU by Freescale for Motorola, so its probably based around an existing (well document) cpu that Freescale were selling during 2002-2002. I see lots of Freescale documentation on the web for their Secure ColdFire (SCF?) technologies.

Its a curious CPU for sure.

Write to me if you know anything about this chip, details on the contact page.


Copyright © 2015 Steven Toth