In 2008 I started a company called Kernel Labs, www.kernellabs.com. Staffed by a hand-full of like-minded individuals, our goal was to develop Linux device drivers, offering consulting services to commercial companies.
Kernel Labs was a success, to a point, we helped over 100 seperate businesses large and small, in all types of industries from airline entertainment, to fitness, home security, cable companies, hardware manufacturers to digital media companies. Times change, people move on, technology moves on, Linux became mainstream.
Kernel Labs exists, but its a shadow of its former self, and that’s completely ok.
We still do occasional projects, we maintain software stacks and services for existing customers. Reach out to me if you’re a Kernel Labs customer and need help, you should have my number and email address.
For the time being I’m taking the kernellabs.com website down, it’s showing its age. I’m redirecting the website back to this blog.
Time for something new!
I have a love/hate relationship with Facebook. Currently I’ve swung towards hate. I’ve stopped reading Facebook. Perhaps in a few weeks I’ll be back. I’m not sure.
For years, I would check the app on my phone 5-6 times a day, I just decided to delete it. It has become a soap opera for me. Its something I don’t need, it’s something that would shape my thoughts in negative directions. I was awkwardly attached to it. That’s not something I need in my life.
I like Facebook when its keeping in touch with Family. I like Facebook when friends are publishing interesting or entertaining articles, family photos or musing their thoughts intelligently. Pictures of I refer to these kinds of Facebook posts as “The Signal”, good social interaction.
My Facebook must be broken. I seem to be getting more “Random gibberish” from various directions. I call this “The Noise”. Noise is nothing more than peoples brain farts materialized from thoughts into form, random English entered on a keyboard and published for all to see. Its the equivalent of giving everyone a Rapmaster 2000 (megaphone).
Don’t even get me started on those “Click Like If You Agree” nonsense posts. They’re articles about current news items, typically Rapists, Child Murderers, or other unacceptible human behavior recently discussed on TV or in the news. We don’t need a ‘Like’ referendum on these articles, its common knowledge, those Murderers are unwelcome aspects of Human society. So, why publish them in the first place? And, what happens if I DON’T click Like?
What happens if your “Click Like If You Agree” article is racist, sexist, homophobic or otherwise backward thinking? Maybe Facebook needs a “You are a Moron for posting this” button.
More often than not, I just ignore your opinions… So if I’m ignoring you, then why do I need to be on Facebook, what’s the point?
I suspect its always going to be that way, maybe I’ll never be back.
Facebook, I’m out for now. The Signal To Noise ratio is just too low.
If you’ve written to me on Facebook and you think I’m ignoring you then … watch this.
Vanessa (wife) bought me a K-Cup machine for my birthday a few months ago. Prior to this I was buying beans and grinding, typically drinking 3 mugs of coffee per day.
K-Cups feel pretty expensive so I’ve tried a few different brands, flavors and price-points. I don’t have any favourites at this point. I think I just like plain old no-frills coffee.
Thinking positively, today I ordered some Organic kups from amazon. Caza Trail Coffee, Organic Extra Bold Medium Roast, 100 Single Serve Cups, at $.35 each, the reviews were good and this seems like a fair price. $35 incl. free shipping with Amazon Prime.
Of course, I’ll reserve judgement until I’ve had the first cup, likely the middle of next week.
Lets hope this isn’t one of those moments when you buy something in bulk and regret it after the first taste.
Update: They arrived yesterday. I’m part way through my first cup this morning. The flavor is a little ‘earthy’ (bold) and rather good. A good purchase. Recommended.
I bought a Nexus 7 Google tablet for family use in 2013, the 32GB unit with the cellular option. The family likes it, no complaints, its a nice device. My wife uses it daily for various different tasks, primarily relaxation, mainly NetFlix and Kindle e-reading.
On an unrelated note: I’m pretty sure she’s made a permanent place in her life for a tablet experience. She uses the household tablets much more than she uses her notebook. I get the sense that she thinks that “Notebooks are for typing work” and “Tablets are for relaxation”. I think I agree.
Oh yeah, the Nexus story. Last week she pointed out that it was no longer charging. It had apparently been “acting up” for quite a while. I switched her to an older iPad and I relegated the Nexus to the shelf for later inspection.
I got around to looking at it today.
First thoughts; Looking at the USB connector, it feels like it has too much movement in it, when the charging cable is connected. The male charging end was moving by 4-5mm in total. That’s more swing than I remembered. I had a hunch that maybe we’re just dealing with an overly assertive user, or general wear and tear. Over time, had the internal solder joints for the 5v rail simply worn out?
I checked the external power supply and cable with another Android device. Its working fine, meaning the problem is within the tablet.
The tablet itself didn’t power on with the charger attached, regardless of how I positioned the usb cable. While this doesn’t necessarily disprove my loose connector theory, generally it points at something else. I continued with the debugging.
I popped the back cover off the tablet easy enough, using a spudger and started looking at the USB connector area itself. A close inspection of the connector showed obvious signs of wear on the delicate internal mating pins. If you look at the mechanicals you can see that inside the housing of the connector is a delicate 5 pin plate. At the rear of the housing, where it attaches to the PCB, are the typical 5 pin mounting/power points.
Internally, the connector looked worn but was firmly fixed in place. Attaching the USB charger and measuring power on the rear mounting pins resulted in a very reliable 5V. The problem wasn’t the USB connector and its apparent 4-5mm motion. The amount of motion in the connector is simply the result of a cruddy mechanical design. I don’t like it at all.
Moving on, I looked at the battery. I measured two 3.8v rails, nothing unusual here. I hooked up the oscillocope to the terminals to see what would happen if I looked at the 3.8v rail while attempting to power the device up. Interesting, I see a small amount of ripple (± 150mv) on the supply, for a few seconds, then nothing else. While attempting to power the unit up, something is drawing current, causing an apparent drop in power. And, best I can tell, the battery has power. The power switching can now be ruled out.
Summary? A dead processor, or other critical component.
No audio is heard when power is applied. No lights appear, no vibration, a completely dead unit. This likely rules out the screen, the battery, the controls and I’ve already ruled out the charger.
While I can’t be certain, given that it has power already in the battery, its probably not the charging circuitry either.
Other than maybe putting the device on the shelf, and repurposing the hardware in a future project, its a dead weight. It went into the garbage today.
If you look carefully at the images you’ll see that the PCB wasn’t perfectly flat on the scanning surface. A mild annoyance I’ve noticed when doing other scanning projects. My quest for fast and easy board scanning solutions continues.
I picked up this board to compare it with a previous card I’d examined a few weeks ago. This card was sourced from eBay, two card for $10 incl. shipping.
Its handy to have multiple devices for testing and inspection - especially when they’re so cheap.
Prior to opening this card, I expected to see the same old story of secure design. That is, BGA components, buried traces, little or no test points. IE. Little or no opportunity for tampering with the design. I was wrong, this hardware is visually much more interesting.
- MT 48LC4M16A2 64Mb SDRAM - Datasheets available
- ST M29W160EB 16Mbit parallel flash - Datasheets available
- SLE88CFX2921P Infineon security processor - Quote: “Chip Card & Security ICs SLE88CFX2921P for Highest-End Security Applications 292 Kbyte Flexible EEPROM 16 Kbyte RAM 32-Bit ROM-less Microcontroller tailored for highest-end security applications with powerful Memory Management & Protection Unit and 1408-bit Crypto Engine (Crypto@1408) designed in 0.13m CMOS Technology By Infineon Technologies Corporation”
- ST 4014163 - Assumed to be a general media processor and the main SOC. I can’t find any significant detail on this, although my assumptions is that’s its a generic ARM with support for DES and other A/V capabilities.
- Why didn’t SA choose BGA packages and follow the CableLabs secure design considerations?
- Why are the traces on the top and bottom layers easily accessible with reasonable debugging tools?
- No onboard battery when compared to Motorola CableCards. Why not? What makes this design not require permanent power vs the Motorola competing product? Curious.
Note the interesting set of pads top right of the board, suggesting that other revisions of the hardware may contain an ISO-7810 sim card interface, similar to those used in Europe for external security chips on CAM / DVB access cards.
I haven’t tried to power the card up, or to look at any pin activity, or so see whether a HDHomeRun Prime can reliably communicate with the card. That’s a task for another day.
CableCard™ has some primary security components that establish trust between interfaces and decrypt and encrypt content. That makes it interesting to me.
In this article I plan to highlight the noteworthy areas in the freely available/public CableLabs documentation. Let’s discussion the primary security mechanisms implemented in the CableCard specification. Let’s get get some terminology down.
Caveat: While I’ve worked on a number of Commercial CableCard projects, I won’t be discussing those and I won’t be giving away any secrets. Everything you read in this article is based on details from publicly available documentation.
- OC-SP-CCCP2.0-I12-120531 - CCCP - CableCARD™ Copy Protection 2.0 Specification
CableCard devices abstract the different proprietary US Cable TV systems into a single common access mechanism that allows third parties to build set-top-boxes or other TV reception devices. With a single standard interface into a CableTV system, and a set of protocol specifications, devices can tune television, and where permitted, receive high-value commercial TV content in an agreeable encrypted format.
In order to maintain high levels of security, third party device manufacturers are required to have their products certified by CableLabs (A central body funded by the US Cable TV operators). These certification tests validate end-to-end trust and security between products, device stability, safety and other things.
I’m interesting in discussing the trust relationship between a third-party device, such as a Tivo, and a CableCard.
How do they trust each other, how is content transmitted securely? What can we learn by examining the public specifications and freely available reference materials?
Card and Host Mutual Authentication
CCCP Section 4.1 outlines the process.
The Card and Host authenticate each other by a process of exchanged messages, calculations using stored secrets, and confirmations that the results meet specific criteria.
Based on a quite read of the CCCP, I’ve made a list of the important secrets and certs.
- c0. Section 5.1.3- Diffie-Hellman shared secret (DHKey) 1024 bits
- c1. Section 4.1a - Diffie-Hellman (DH_pubKeyc) public key from c0. - Section 5.1.2/3, DH prime (DH-n) is 1024 bits - Section 5.1.2, DH base (DH-g) is 1024 bits
- c2. Section 4.1a - Diffie-Hellman (DH) generated random integer.
- c3. Section 4.1b - X509 Device Certificate (public key and private) - No mention of passing the public key to the Host - In section 5.1.1
- c4. Section 4.1c - Root Certificate, used to sign all h5 and c5
- c5. Section 4.1c - Manufacturer Certificate - Used to sign c3
- c6. Section 4.1c - Signature of c1
- c7. Section 4.1e - DHKey - a shared secret between CableCard and Host - Section 5.3.4 - Stored in non-volatile memory
- c8. Section 4.1f - AuthKeyC - Card to Host shared auth key. 160 bits - Section 5.4 - Stored in non-volatile memory
- c9. Section 4.3 - Random integer ‘x’ used for DH. - Section 5.1.3 DH Private Exponents x,y 160 bits - Generated for each different binding
- c10. Section 4.3 - CPKey - Copy Protection Key calculated from c9 - Using SHA-1 and DFAST , , . - M-card multi-stream, each stream has its own CPKey/DESKey. - Table 8.2.1 - M-mode uses two 56-bit values
For the Host (Tivo, TV, set-top-box):
- h0. Section 5.1.3- Diffie-Hellman shared secret (DHKey) 1024bits
- h1. Section 4.1a - Diffie-Hellman (DH_pubKeyH) key derived from h0.
- h2. Section 4.1a - Diffie-Hellman (DH) generated random integer.
- h3. Section 4.1b - X509 Device Certificate (public key and private) - Device public key is shared with the CableCard.
- h4. Section 4.1c - Root Certificate, used to sign all h5 and c5
- h5. Section 4.1c - Manufacturer Certificate, used to sign h3/c3
- h6. Section 4.1c - Signature of h1
- h7. Section 4.1e - DHKey - a shared secret between CableCard and Host - Section 5.3.4 - Stored in non-volatile memory
- h8. Section 4.1f - AuthKeyH - Card to Host shared auth key. 160bits - Key is set to Card during Copy Protection Init Sec 5.2 - Section 5.4 - Stored in non-volatile memory
- h9. Section 4.3 - Random integer ‘y’ used for DH. - Section 5.1.3 DH Private Exponents x,y 160 bits - Generated for each different binding
- h10. Section 4.3 - CPKey - Copy Protection Key calculated from c9 - table 8.2.1 - M-mode uses two 56-bit values
- h11. Table 8.2.1 - KsA/B (DFAST Seeds) two of them, 128 bits each
Section 4.3, triple-DES is used to protect content from the CableCard to the Host, using c10 for encrypt and h10 for decrypt (symmetrical scheme, so they’ve compute the same secret key).
Section 4.5, M-Card mode uses triple-DES (ABA) in ECB mode. So any encrypted data being transmitted from the CableCard to the Host using a standard symmetrical encryption scheme. No all content is necessarily transmitted in an encrypted for, the CableCard firmware decides this based on CCI flags specified by the CableTV Operator itself (traditionally negotiated via legal contracts with the content providers, FOX, HBO, AMC etc).
Evaluation certs are available:
Sample evaluation certificates for c3, 4, 5 and H3, 4 5 are available for download from the CableLabs website here .
The Card SHALL contain a CHICA-authorized X.509 version 3 Device Certificate [X.509] and matching private key used for creating digital signatures. This certificate includes a unique ID and the public key provided to other devices to validate the digital signatures.
Item h3 and possibly c3 (optional).
The Device certificates h3 are validated by the manufacturer certificate h5 which in turn is validated by the root certificate h4. All the certs are chained and validated as signed by the CableLabs signing authority.
Its typical for the CableLabs root (c3/4/5) certs also to be present in the CableCard, so aid with the verification of the cert validation chain.
Diffie-Hellman Public Key Calculation
An evaluation implementation of DFAST has been made available by CableLabs .
A cursory glance at the eval code suggests that CableCard and Host implementations of the Production (secret) version of this software probably has a 256 * int sized pair of byte substitution tables, tables of numbers that never contain the same value twice. This should be easy to find if you had access to non-encrypted firmware for either a CableCard or Host device. Have you checked the Service Channels of your cable plant recently?
I’d also hazard a guess, looking at the eval code, that the coefficients that are in static arrays before the two translation tables are also placed close to or near the translation tables in any production firmware. This is also interesting.
Result is this DFAST computation is DKHey.
The Card SHALL derive a Diffie-Hellman (DH) public key and its signature as follows: generate a random private exponent, x, where 1 ≤ x ≤ n –2; compute its DH public key as DH_pubKeyC = gx mod n; compute SIGNC by signing DH_pubKeyC with its X.509 private key.
This comment is interesting. A publicly visible item of data, calculated at card bind time (when the card is paired) is likely stored in non-volatile memory, perhaps a secure key store or a simple flash device with minimal protection. This data item may be stored near or in the same place as all the other secrets. This is useful to know.
A logic analyzer on the control bus could visually inspect the contents of AuthKey and later analysis of a device (or memory image) of a device, may yield interesting near-by neighbor data items.
After calculation of AuthKeyC, the Card SHALL request AuthKeyH from the Host using the CP_data_req() APDU with Datatype_id = 22.
DFAST is also used to calculate the h10/c10 copy protection key, hmm.
Allocation of production certs:: www.cablelabs.com/resources/digital-certificate-issuance-service/#tabs-785
For many years TV’s used ‘canned’ tuners. These were analog electrical components mounted on PCBs then wrapped in tin cans. These ‘tuners’ were the RF sub-system of your traditional TV. In terms of size they are about the size of your index finger.
You connected your antenna to the input of your TV, which is the input to the can, tuned your device (tuned the can) and the device received the radio frequency and handled all the magic related to extracting the sound and images being broadcast. They did one job exceptionally well.
Canned tuners are no more, technology marches on.
The industry re-invented itself in the early 2000’s and shrunk those metal cans down into single integrated circuits (chips). See the picture above. Silicon tuners today are significantly smaller, around the size of your finger nail!
Analog TV image quality from those early silicon tuners was deemed questionable by some, and rightly so, but the writing was clearly on the wall for the legacy canned technology. The Silicon Valley micro-chip companies were out to re-invent TV tuning technology.
If you’re interested in the science behind TV RF tuners, canned and silicon, how they manipulate and select RF, then you’ll like this document courtesy of FreeScale Semiconductors.
Fair warning, the document is a little dated but still gives a great overview of the basic problem space of mixing, down conversion, LNAs and AGC. The document goes on to describe how two of FreeScales particular products attempt to solve those issues.
While I don’t recommend using FreeScale tuners today, I’m happy to recommend this introductory document.
Wikipedia defines Vital Product Data as
“…a collection of configuration and informational data associated with a particular set of hardware or software. Vital product data (VPD) stores information such as part numbers, serial numbers, and engineering change levels”
When hardware manufacturers design a product they often add a small data storage device to the design.
This storage device (an EEPROM) contains important information specific to each individual product. EEPROMS are inexpensive and have minimal capacity. They typically store 256 or 4096 bytes, not megabytes. A few bytes of storage is enough to make any device unique, to have its own ‘personality’, to differentiate one device from another.
Having each customer product be unique is highly desirable, often mandatory for use. Its often a govermenment or legal requirement, depending on the type of product.
During manufacturing, shortly after the product has been assembled, the Contract Manufacturer (CM) is usually required to run a custom software application inorder to check each device is functioning properly. The application looks for defects, runs unusual tests and may caliberate certain device functions (touch screens). When electronic behaviour varies between devices then they may require caliberation. The results of this process are permanently stored in the device. When a consumer uses the device, the caliberation information can be used by the device itself to ensure proper functionality.
The application is generally referred to as Production Test. Its written by the manufacturer of the device… Such as Apple, Samsung or Microsoft. The application is given to the CM for use in their Production Test facilities.
One Production Test is complete, final stages often include allocating a unique serial number for the device, ‘burning’ this information into the onboard device storage. This is usually done using hidden electrical interfaces or obscured factory programming interfaces.
A great example of this unique serial number is the IMEI in your cell phone.
Sidenote: Rarely do CM’s leak the Production Test software to the public although occasionally it does happen. It’s a good day when this happens.
Every car has a unique identifier, partly for legal reasons, partly for maintenance reasons.
Every PC has an internal serial number and unique network address. Partly for maintenance reasons and partly so that your PC can co-exist on a network with other PCs without confusing the network.
Unique identifiers are as useful as they are important. We need them.
Interestingly, as technology advances and manufacturers have attempted to limit the behaviour of their devices, depending on the contents of the VPD, thousands of commercial companies and home enthusiasts have been attracted to hardware hacking, altering or ‘upgrading’ their VPD to unlock new and unusual behaviours.
Sidenote: I once heard a story in the early 90’s related to IBM. In the 70’s, it was common practise to ship mainframes to customers with various internal performance limiters. A $2m mainframe was exactly the same hardware as the less expensive $1m mainframe, but the $2m model has a feature resister ‘cut’ by the IBM engineers to improve the speed. As a 20 year old this shocked me greatly. Today, I completely understand this behaviour and business practise. IBM didn’t design a cheap and expensive model, they designed the expensive model and made it available to more customers less-expensively with lessor features. At the time, I did wonder innocently whether anyone thought to hack this.
The same high value / low value price differentiation happens today in the automobile industry. Consumers can purchase cars with features that are ‘software unlocked’ by the dealer.
Some people object to this, much like my earlier objections to IBM, although most people are unaware or have no opinion.
Enthusiasts have a long history of modifying their products to adjust behaviour.
Basic examples of this include chipping / tuning your car, upgrading your digital camera to improve performance or unlock hidden features, Cloning mobile phones and pagers (back in the day), jailbreaking your cell phone in order to remove carrier locking restrictions. Adjusting the power of your wifi router higher than local laws allow. The list goes on.
Its dangerous and probably illegal in some countries to modify electronics, clone devices or adjust vehicle performance. People do so at their own risk.
In the world of Audio/Video capture cards, companies such as Hauppauge Computer Works store multiple data types in their VPD records. As a Linux developer, attempting to create Open Source drivers for their products, its helpful to understand these VPD records in order to build better device drivers.
… and yet we rarely do.
drivers/media/video/tveeprom.c contains a function:
void tveeprom_hauppauge_analog(…, struct tveeprom *tvee, unsigned char *eeprom_data);
It takes a array of bytes and attempts to decode Hauppauge’s production programming information (VPD). The results are stored in the tvee struct and can be passed around inside the driver to influence behaviour.
The data is not considered secret and if you compare the data taken from one device to another, generally the only difference you’ll notice is in the serial number field.
When it comes to a/v capture devices and VPD, I consider Hauppauge the ‘Gold Standard’. Their VPD is easy to access and Hauppauge Engineering have never refused a question from an enthusiast on its format, they’re helpful. That being said, you get little or no benefit from modifying Hauppauges VPD.
AVerMedia, and other companies rarely use VPD in their PCIe devices so they’re slightly more difficult to integrate into multi-capture commercial workflows. I’d prefer at a minimum they allocated a VPD serial number.
As you can see by looking at tveeprom.c above, Hauppauge go to great lengths to store the type information for important PCB sub-components, including Tuner and Demodulator type codes. In theory, any Windows or Linux device driver, rather than assuming product XYZ has a Philips Tuner and a LG Demodulator, can look at the manufacturing data to understand and support their sub-components.
This allows Hauppauge to keep product XYZ selling in retail, without changing its name, but slowly improve the design over time by changing Tuners, Demodulator and other components.
Its a good example of a data driven design.
The VPD indicates which components are installed on the PCB, the device driver attaches the appropriate software to its running model to differentiate product XYZ rev1 from rev2. Therefore, one device driver supports multiple revisions of a product.
Linux device drivers DO NOT do this. Instead they rely on the differences in their PCIe sub-vendor and sub-device fields to make runtime decisions about which subcomponents are installed. This isn’t a terrible approach, especially when a Linux driver supports Hauppauge and other vendor boards… But its a pity that the VPD for Hauppauge boards isn’t relied upon a little more, especially for exposing serial numbers to user space applications.
Commercial Needs - Multi-channel Capture
VPD serial numbers are useful for commercial customers using Linux drivers. They often deploy multiple capture products in a single server and need a reliable way to associated a V4L2 (analogTV) or DVB (digitalTV) device node with a physical RF TV feed.
At Kernel Labs we write and license Linux device drivers for many products.
One good example is the Hauppauge Colossus HD Capture card. Its a Component and HDMI card that is used by multiple commercial customers for 7x24 capture, recording and media monitoring.
For this driver, and for many other drivers we’ve written, we specifically parse the hardware VPD and expose the hardware serial number to user applications through sysfs. The benefit here is that its trivial for user applications to query sysfs to find a specific capture card by serial number and use this to also locate its Video4Linux2 device nodes.
In summary, a well written application, instead of asking the user to supply a DVB adapterNr on startup asks for the device serial number. Customers don’t care about adapter numbers, they care about RF input signals, and those are attached to capture cards with unique serial numbers that are easy to locate in any server, under any circumstances, with any mix of capture cards.
Consider the case where users are capturing from two devices simultaneously. Due to system failure, software updates or device enumeration changes, the DVB adapter numbers change beyond the customers expectation, they switch around. What was once on adapter #2 now appears on adapter #1, and vice versa. That’s bad for commercial customers who need 100% predictability with signal acquisition.
Assume you have 8 capture cards in a server, which command line syntax do you prefer?
- ./data-recorder-app -a AdapterNr
- ./data-recorder-app -c Serial#
The difference is subtle, until adapternr 0 breaks and has to be removed, then every other adapter can (although not always) shuffle. At this point the commercial customer usually calls and isn’t too thrilled.
Forward planning during driver development and proper VPD handling avoids issues like this.
Certain kinds of devices hold much more than serial numbers and vehicle horse power limitors. These typically have very large storage devices and hold megabytes of data, including firmware.
Tivo CableTV set-top-box devices store secure Cable TV network certificates. Some of these are public and can be downloaded directly from CableLabs, others are considered highly secret and should not be easy to extract using ‘typical debugging equipment’.
Examples of these are the device specific DTCP/IP or CableCard paring certificates.
Assuming you knew how to extract these certificates, you could feed those certificates into an open source implementation of a DTCP/IP stack and obtain highly valuable TV signals without DRM from some typical US CableTV devices.
TV enthusiasts like to prod and probe their Tivo boxes, all sorts of interesting details can be found on their internal hard drives.
Scratching an Itch
I recently visited the UK. I noticed that my rental car automatically retracted the side mirrors when the engine was stopped, bringing the mirrors close to the body of the vehicle. A neat feature.
My US vehicle has a similar feature but its completely manual, I have to elect to fold the mirrors in, flipping a button, or use the remote to trigger it.
Wouldn’t it be interesting if I could attached to the On Board Diagnostics vehicle interface, send a basic message to the car to (presumably) enable this feature by default? I think so.
Or, use an iBeacon proximity sensor, my iPhone and a blue-tooth OBDII interface to send some custom commands to the vehicle as my phone left or entered the proximity of the vehicle? Oh, that’s getting interesting, I might look into this.
Enthusiasts are already adjusting their vehicle behaviour, its nothing new.
To VPD or not VPD, that is the question.
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
- SCF6100VM - Freescale Microprocessor, image
- 320W18BD - Intel Fash Memory, family datasheet, image
- D9GRQ - Micron SDRAM, family datasheet, image
- Battery. image
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.
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