# CableCard experiments



## telemark (Nov 12, 2013)

No results yet, but creating this for those trying to develop a way to save CableCard pairing across Hard Drive upgrades to have their own thread.

A little discussion sparked from here.
http://www.tivocommunity.com/tivo-vb/showthread.php?p=10203141#post10203141

There is a CableCard tear down:
https://technology.ihs.com/Teardowns/detail/?ids=336863_515
Again, only thumbnail viewable. The POD2000 ones.

Round thing looks like a battery to me.


----------



## AllYourBase (Oct 24, 2007)

```
bash-2.02 # mfs_dumpobj /State/Cablecard
Cablecard 43745/10 {
  IndexPath      = /State/Cablecard
  NonVolitileData = 512 <1024 bits of serial data>  ...
  PodId          = 0
  PodSerialNumberHi = 0
  PodSerialNumberLow = 85240964
  TuningResolverAttached = 0
  Types          = 2
  Version        = 5
}
```
And a socketed S3 helps if you really want to prod this.


----------



## telemark (Nov 12, 2013)

I'm glad that's over.


----------



## eboydog (Mar 24, 2006)

I'm not a hex coding guru programmer tech so forgive my layman question....

Does the "Data" value change because the drive is changed or is that data stored on the drive and when a not found, a new value is created?

I always assumed once a card was paired in a Roamio, it was paired, but it swapping drives,  it changes of course and makes the pairing info invalid.

Now if I put swap drives in a Roamio were the card is paired and don't have my CC re-pair the card, if I put the original drive back (that the card was successfully paired); will the Data value remain the same or will it change because it detects a drive change?


----------



## wmcbrine (Aug 2, 2003)

telemark said:


> I'm glad that's over.


----------



## telemark (Nov 12, 2013)

eboydog said:


> Does the "Data" value change because the drive is changed or is that data stored on the drive and when a not found, a new value is created?


I haven't studied it first hand. I can only provide some theories from observations others have reported. 
My working theory is cause the matching data on the drive is missing. Time will tell.

The Roamio hardware has no state. A Roamio does not know you swapped out the Hard Drive. A CableCard apparently has state because moving it to another box and back does not revive the prior link.

If you clone two hard drives, you should be able to swap between them and the Cable Card should not know, if that field is static. If that field is dynamic, then you'd have to resync the field as well.

I suppose that should be a test. Clone a drive. Swap to new clone. CC should still work. Swap back to old clone, CC would ideally still work.

There's a number of ID's on the system's hardware if the software wants to key off of a box specific value, but even if that happens the hard drive's S/N would be unlikely probability-wise.



wmcbrine said:


>


Maybe I should have used a smiley. I started the thread cause I was told the CableCard data had unknown whereabouts. Since it was already known to others, in my head the hardest part is overcome. That could prove to be wrong, but that was my initial sentiment at least.


----------



## jmbach (Jan 1, 2009)

AllYourBase said:


> ```
> bash-2.02 # mfs_dumpobj /State/Cablecard
> Cablecard 43745/10 {
> IndexPath      = /State/Cablecard
> ...


Interesting. So the question is where on the drive is the actual data located. I am assuming it will be within partition 10 as that has a lot of pertinent data for TiVo operation. A quick scan of it reveals two blocks of data that contains references /State/Cablecard. Not sure if it contains the actual data or a pointer to where it is stored.


----------



## nooneuknow (Feb 5, 2011)

telemark said:


> I haven't studied it first hand. I can only provide some theories from observations others have reported.
> My working theory is cause the matching data on the drive is missing. Time will tell.
> 
> The Roamio hardware has no state. A Roamio does not know you swapped out the Hard Drive. A CableCard apparently has state because moving it to another box and back does not revive the prior link.
> ...


This is with 746320 Premiers and 652160 TiVo HDs, with Cisco/SA PKM802 & PKM800 cards:

I had tested, so many times I lost count:

Test 1: Swapping drives invalidates my pairing, even if each of the drives was in (one at a time), when I paired the (same) card.

Test 2: If I took the same identical model (stock) drives, paired the card to one, and cloned sector-by-sector to the other, then installed the (target) drive, my pairing was gone. If I then put the original (source) drive back in, the pairing remained gone.

*EDIT/INSERT: It didn't used to be this way until one version of firmware rolled to the cards. It stayed that way with future updates.*

I repeated these exercises so many times, Cox told me that any more pairing calls would require a truck roll to figure out what was going on. I couldn't tell Cox what I was doing, or it would be bad (I speak from experience). Somehow, my cards (and something odd about my cable market, compared to others) knows the drive has changed. I had quit posting about this, due to the number of people telling me it was impossible, or I was cloning the drives wrong, or doing something else wrong...

As far as the Roamios go, my limited cablecard/drive swapping experience is limited. The one with the drive that had the weak sectors, would not lose pairing, even with a C&DE, repeated at least 10 times. Every scenario that should have made it lose pairing (except drive changing, which I have yet to put another drive back in that Roamio, and it's been down so long I expect it will not be paired when I put a different drive in, even if I put the same one in, since I had to zero it to reclaim those sectors).

*EDIT/ADD:* The other two Roamios, wouldn't lose their pairing, when I called and asked Cox to un-pair them. I had to spend a whole day trying to force the pairing to be lost, doing everything short of a C&DE. I don't recall what finally resulted in the pairing being lost. I just remember that no channels were working, and part of me trying to get the TiVos working again was to try to do an un-pair & re-pair. Once I got that to happen, and re-paired, operation returned to normal. How did the no-channel state come to be? I returned some TAs and cablecards a few months after selling all my HD and Premiere TiVos, after getting my base Roamios. The Cox store rep had been lazy, and picked what I returned out of a list of what I had, and put in the system I had returned some of what I had kept. I caught the error at the Cox store, before leaving the service counter, and had it corrected. I came home to nothing working at all, except my cable modem.


----------



## AllYourBase (Oct 24, 2007)

eboydog said:


> Does the "Data" value change because the drive is changed or is that data stored on the drive and when a not found, a new value is created?
> 
> Now if I put swap drives in a Roamio were the card is paired and don't have my CC re-pair the card, if I put the original drive back (that the card was successfully paired); will the Data value remain the same or will it change because it detects a drive change?


Tivo's cable card implementation follows the OpenCable Specification, so some reading of this: link will answer most questions.

From a layman's perspective, the "pairing" of a card results in both sides storing a unique shared secret and the ID of the other. Tivo stores the cablecard's ID and the shared secret in its MFS database. Pairing the same cablecard and tivo multiple times would result in multiple, unique shared secrets (DHKey). And during boot, if either side detects a change (in either the ID or in the DHKey), then it irrevocably discards any pairing information (meaning the cable card need to be re-paired by the provider).

A cloned drive preserves the /State/Cablecard object in MFS and thus preserves the pairing. But the cable card will detect any drive with a missing or old /State/Cablecard object and unpair itself. After that, reverting the drive does no good, as the cablecard has already destroyed its pairing. Exactly what would happen in your "swap" drives example above, eboydog.

Complicating matters is that providers may require that cards be activated, but not necessarily paired (to display content), or may require pairing for protected content, or may require pairing for any and all content. Further still, there are different brands of cards and different firmware revisions to those cards. So some tivo users encounter few problems (Verizon) while others need a truck roll if they even think about touching their cablecard (TWC).

However, one can meet the goal of most users (to swap, change, or upgrade drives without needing the provider to re-pair the card) by exporting /State/Cablecard from an existing drive, and importing into any new drive. The roamio's ability to rebuild a blank drive complicates the timing of this, but tools to backup and restore roamio drive images should solve that.

@jmbach As stated above, /State/Cablecard lives in MFS, so you'll need mfs-utils from a PC, or a tivosh on a running unit to prod it.

@telemark the drive ID doesn't factor into the interactions, only the tivo's CableCard Labs issued certificates matter.


----------



## telemark (Nov 12, 2013)

Generally matches my understanding of everything and well written.



AllYourBase said:


> @telemark the drive ID doesn't factor into the interactions, only the tivo's CableCard Labs issued certificates matter.


Not disagreeing, but saying it doesn't match all reports, like nooneuknow's report.

In AllYourBase's model, only the Certs matter.
In nooneuknow's description, somehow the drive had leaked into the ID phase.

@nooneuknow:
On a practical note, if you don't have boxes + cards that exhibit this behavior anymore, it'll be difficult to demonstrate why it does that. I do have theoretical explanations for everything but without the boxes in question, it might be moot to include something no longer testable. If you still have them however, then they're worth incorporating if there's a way to do so.

It's easier making migration code for the common case, distributed testing, and deal with exceptional situations where it broke when they happen.


----------



## jmbach (Jan 1, 2009)

AllYourBase said:


> Tivo's cable card implementation follows the OpenCable Specification, so some reading of this: link will answer most questions.
> ...
> However, one can meet the goal of most users (to swap, change, or upgrade drives without needing the provider to re-pair the card) by exporting /State/Cablecard from an existing drive, and importing into any new drive. The roamio's ability to rebuild a blank drive complicates the timing of this, but tools to backup and restore roamio drive images should solve that.


Thanks for the info. It has enhanced my understanding.

On a Roamio, this could be done by powering down the Roamio, remove the drive and CableCARD, putting in the new drive, let the Roamio build the drive, pull the drive and import from the old drive the appropriate information, then put the new drive and the CableCARD back in the Roamio and allow it to boot.

Wondering if with telemark's 4TB community image if the appropriate information could be imported on its creation and when it boots in the Roamio it would survive finalization of the image.


----------



## telemark (Nov 12, 2013)

Maybe tangential, but if we wander into some details, readers might want an overview familiarity with Diffie-Hellman-Merkle* key exchange.

I don't know which tutorial is good but there should be some at the end of Wikipedia.
http://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange

* Merkle was a Berkeley student when inventing the concept but was failed by his professors for proposing an impossible idea. Stanford Profs Diffie and Hellman adopted him, fixed and published a system that was complete, which the world named after them. Unable to locate a critical piece, another team Rivest-Shamir-Adleman extended their work and gave us RSA, a public key cryptosystem.

Edit: the wikipedia graphic is as (over?)simplifed as you're ever going to get.
[media]http://upload.wikimedia.org/wikipedia/commons/a/a9/Diffie-Hellman_Key_Exchange.png[/media]


----------



## telemark (Nov 12, 2013)

jmbach said:


> Wondering if with telemark's 4TB community image if the appropriate information could be imported on its creation and when it boots in the Roamio it would survive finalization of the image.


That's a long discussion, so let's save it for when it's time to cross that road. It could be done but with a number of caveats, some of which might make it not worthwhile.


----------



## nooneuknow (Feb 5, 2011)

There's some great info/data/external links here. Thank you, all, for this. About the only "what more I could ask for" is that I could have persuaded the other members of the TCF brain bank, with the ability to understand MFS and coding, to take this on while I still had Premieres and TiVo HDs here to use for my cable-market-specific cablecard pairing losses, that have simply been dismissed/rejected until telemark joined in.

Here's some issues with trying to participate (with Base Roamios) :

The Base Roamio has the cablecard slot enclosed by a plastic cover, on the underside of the TiVo. This cover has one of the rubber feet attached to it. It's difficult to get the cover off (in the way I made a stacked, but well-ventilated TiVo rack), without completely disconnecting mine, and it's just as hard to set/unseat the card, without doing the same. Unless it is easy to flip the TiVo upside-down, there is difficulty in working with the card, and dangers that are made worse, like the next point will address.

The Base Roamio has an issue-prone cablecard slot, which eboydog is all-too-familiar with. Unless treated with excruciating levels of care/caution, it will fail, due to slot-board flexing of the solder joints for the slot. Even with extreme care/caution, I fear that I could render the slot inoperable. I have already lost the plastic end that goes on the razor thin/sharp end of the eject lever on one, using it properly and carefully, for the second time I ejected a card (done during things I was trying, when I couldn't force the card to lose pairing). It's all friction fit, not the clicking, low force, action of older slots with an eject mechanism. Not using the lever (or not being able to) is bound to damage the solder joints, as there is no room to grab the end of the card, leaving only the worst way to unseat/re-seat, by pressing down hard on the face of the card and using forceful finger friction. I can still use the lever, with an improvised tool used rather than slicing my finger open and getting blood in my TiVo. I still fear just how many times proper use of the lever it will take to break the solder joints (or something else gives). I don't think it will take many, at all. eboydog has been very vocal about this. But, that's not the source of my concerns (just a confirmation of them being valid).

I still have two TiVo HDs I could've used to prove what I say, and create backup images of to share with the rest of the class. Unfortunately, I had given up on anybody believing a perfectly cloned drive, with only a different serial number, would nix the pairing that was on the source drive. I sold the power supplies, recently, since it seemed silly to think I'd ever get anybody to take these matters on.

The fact that so much software can get the S/N of the drive, and the fact that the model is identified by KS54, and is also in the TiVo logs, makes it seem silly to think the S/N is just being ignored, IMHO.

I'm so happy that this is all being looked at now, yet rather afraid that my market-specific drive S/N change invalidating pairing condition will still get left behind. I either have to risk my lifetime Roamios to work with the Roamio side, or I have to rig up makeshift power supplies for some old no-sub TiVo HDs, to try to work with that side of things...


----------



## telemark (Nov 12, 2013)

Does someone know, or could someone track down when does /State/Cablecard first get created?

Something like:
C&DE*, is it there yet?
Guided Setup, how about now?
Insert CableCard, should be there now.

*= a little better than C&DE would be a factory fresh image or the 4TB image.


----------



## jmbach (Jan 1, 2009)

In GS there is a check for the CableCARD asking you if you want to insert it or skip for now. So certainly there is something around that time. So another question would be if the card is inserted at first boot, is the card information there when the GS start screen is up.


----------



## nooneuknow (Feb 5, 2011)

jmbach said:


> In GS there is a check for the CableCARD asking you if you want to insert it or skip for now. So certainly there is something around that time. So another question would be if the card is inserted at first boot, is the card information there when the GS start screen is up.


Yes, the cablecard info on the diag screens will be available to you at that point in GS, if you insert the card before even beginning GS with a virgin drive (for Roamio). The Premieres and HDs also will skip the "insert card now/later" screen, and instead tell you a card is inserted, and let you read the cablecard diag screens. If you wait to insert the card at that point in GS, it will take some time (up to 20 minutes), for the card to fully boot, and download all the tables/data to the card. If the card has previously been paired recently, especially if to that Host ID, it takes less time.

Sometimes the cards have to download all the tables/data/parameters from scratch, due to any one of a number of scenarios. Sometimes the cards only need to download what is typically updated during scheduled refreshes, which takes much less time.


----------



## HerronScott (Jan 1, 2002)

I just upgraded one of my S3 OLED's from a 1TB to a 2TB drive and did not lose the CableCARD pairing in the process. This is with Comcast using Cisco/SA CableCARDs. The CableCARD ID and Host ID stayed the same for each card (2 CableCARDs in an OLED).

I've got a second one to upgrade this coming weekend and will report back if it goes any differently.

Scott


----------



## nooneuknow (Feb 5, 2011)

HerronScott said:


> I just upgraded one of my S3 OLED's from a 1TB to a 2TB drive and did not lose the CableCARD pairing in the process. This is with Comcast using Cisco/SA CableCARDs. The CableCARD ID and Host ID stayed the same for each card (2 CableCARDs in an OLED).
> 
> I've got a second one to upgrade this coming weekend and will report back if it goes any differently.
> 
> Scott


Was this an upgrade where you used an image of a drive with the pairing intact, as the base to expand upon? If so, this is the expected, normal behavior, if you exclude my apparently "local Cox market" weirdness.

If you are saying you started off with an unpaired image to expand upon, but the status reported by the card reflects paired and authorized, I would imagine that the card will lose pairing when the next scheduled refresh happens, which extends-out how long it is authorized to decrypt.

It is possible for a card to state it is both paired & authorized, when conditions are "just right", and you are on a cable system that is lax/loose on how much has to be different/changed before the card/system invalidates the pairing.

There's a lot of cable market and YMMV variations in play. But, any data is good data, so long as everybody knows and understands the context of the data.


----------



## ggieseke (May 30, 2008)

telemark said:


> Does someone know, or could someone track down when does /State/Cablecard first get created?
> 
> Something like:
> C&DE*, is it there yet?
> ...


It's there in my "factory fresh" 748 image. It's only 72 bytes, but it's there.


----------



## HerronScott (Jan 1, 2002)

nooneuknow said:


> Was this an upgrade where you used an image of a drive with the pairing intact, as the base to expand upon? If so, this is the expected, normal behavior, if you exclude my apparently "local Cox market" weirdness.
> 
> There's a lot of cable market and YMMV variations in play. But, any data is good data, so long as everybody knows and understands the context of the data.


Yes, this was imaging from the existing 1TB drive which had pairing intact and this was meant just as another data point. 

Scott


----------



## nooneuknow (Feb 5, 2011)

ggieseke said:


> It's there in my "factory fresh" 748 image. It's only 72 bytes, but it's there.


Anybody else wondering if this is "just too easy"?

I'm wondering if that cablecard state pointer is meant to direct the attention of prying eyes away from where the actual pairing data is...

Other closed ecosystems, like Playstation/Xbox have gone as far as fake BIOS bootstraps (or whatever the famous "belt sander" to the gaming console board exposed), to divert attention away from where the real "secret handshakes" happen. I'd imagine the fact that people hacked their way past that, but TiVo still remains secure, might mean there could be some major intentional misdirects with anything related to content protection.

I think we may need to tread carefully, as this is getting into content protection mechanisms, and what we are looking for, no matter how innocent our intentions, might fall afoul of the ban on discussions about "circumventing" content protection mechanisms.

I know I'm often naturally in a paranoid state. So, I welcome anybody to help assure me that we're not going into the "danger zone", by simply trying to find the location of this data, and find a way to "preserve" it, then restore it to another drive (or even the same one, after a re-image), and not set off any nullifying mechanisms...

I know I'd be more willing to experiment, if I could eliminate dealing with Cox, and explaining I don't need a truck roll, but just need the paring re-established (but can't tell them how it wound-up lost, for the 30th time in a month)...


----------



## telemark (Nov 12, 2013)

Sharing some of my notes. Found some OCAP .jar files on my backup images.

If you google some of the java paths:
org/ocap/hardware/pod/POD
org/ocap/hardware/Host

You'll find code bases:
https://community.cablelabs.com/svn...OCAP-1.0/java/src/base/org/ocap/hardware/pod/
http://grepcode.com/file/repo1.mave...ya/ocap-api/1.2.1/org/ocap/hardware/Host.java

And two overviews:
http://docs.huihoo.com/javaone/2007/consumer-technologies/TS-0011.pdf
http://www.drdobbs.com/jvm/java-the-opencable-application-platform/184405724

PS. ya, I don't understand everything they're talking about either.


----------



## telemark (Nov 12, 2013)

@ggieseke: Thanks for that.

@nooneuknow:
I think it's more likely it's that easy versus it being a misdirect. I say that because it's low value as there's limited other uses (the key only works between same CC and Host). Tivo's relatively decent at securing what it wants to, which is apparently content protection and access to the OS / root.

Whether it's too close to forum policy, I'll defer to the veterans of the forum for their judgment.

Regarding data points: one of the recent installs on the 4TB thread said they didn't have to contact Comcast to re-pair. It would near impossible for them to have migrated that data over accidentally aside from mixing up the drives. Time will tell if it gets invalidated.


----------



## nooneuknow (Feb 5, 2011)

telemark said:


> @ggieseke: Thanks for that.
> 
> @nooneuknow:
> I think it's more likely it's that easy versus it being a misdirect. I say that because it's low value as there's limited other uses (the key only works between same CC and Host). Tivo's relatively decent at securing what it wants to, which is apparently content protection and access to the OS / root.
> ...


Just don't forget how many people post arguments against those who do have to re-pair plus get to a fully authorized, and fully functional, state, and the reason is often that their (former person's) MSO only requires pairing and auth states for premium channels, which such a person posting re-pairing is/was not needed, may mis-state as they "kept their pairing", when there is/was no pairing, and they may have never had pairing, or lost it, without adverse effects.

On the opposite end of the spectrum, I've experienced many issues where the card takes the pairing, but fails to become authorized to decrypt "pak" channels, of which most are Encore movie channels, and what is sometimes considered "premium", like Epix, or even just odd ones like IFC and BBC America (variety pak). This is often the hardest state to resolve, for me.

It's an issue for both Moto and Cisco cards, the pairing plus authorization (two different things, of which both parts are needed, to have the card in a fully paired/auth'd state).

I've been brushing up on what all the acronyms in the cablecard and TA screens stand for, and what the values displayed represent. It sure helps a lot to know them. The most helpful guide was actually the Cisco STA1520 manual/guide for MSOs. Before this, I only knew which ones mattered, and what values were good and bad.

Speaking of TAs, there is a pairing of the TA to the card (within my regional Cox market, but not used in others), which might also be a crucial component of keeping things paired and authorized. It has gotten so "locked-down", that all these variables, of which some have no need for, I'm stuck needing all of them, just to get anything beyond digital basic starter tier (which still requires pairing, but not the auth state).

So, when it comes to data points for the most locked-down markets, I guess I'm the source, even though very little use of the CCI-byte is used here (in this oddball Cox market). I think the mystery issues I have are Cox using a different manner of content protection. Even though my market is "back in the fold", it used to be a rogue Cox breakaway, which did as it pleased, even though the Cox franchise didn't approve. They still have that bit of "maverick" to them. So, it's hard when I'm the only one reporting-in from my market...


----------



## ggieseke (May 30, 2008)

I don't *think* that it's dangerous territory. First you have to be able to parse the MFS file structure, then you have to be able to actually read tyDb files. Note that AllYourBase used a hacked S3 to even run "mfs dumpobj" at the bash prompt.

Additionally, the only value I can see in it is the possibility to back up the pairing by pulling the hard drive. Assuming that it's even worth the effort, the existing tools like MFSLive or DvrBARS should copy that file to the new drive. Using that data to actually do anything to the CableCARD like adding HBO to your account would be impossible. We'll be darn lucky if it even copies the pairing for a majority of users.


----------



## nooneuknow (Feb 5, 2011)

ggieseke said:


> I don't *think* that it's dangerous territory. First you have to be able to parse the MFS file structure, then you have to be able to actually read tyDb files. Note that AllYourBase used a hacked S3 to even run "mfs dumpobj" at the bash prompt.
> 
> Additionally, the only value I can see in it is the possibility to back up the pairing by pulling the hard drive. Assuming that it's even worth the effort, the existing tools like MFSLive or DvrBARS should copy that file to the new drive. Using that data to actually do anything to the CableCARD like adding HBO to your account would be impossible. We'll be darn lucky if it even copies the pairing for a majority of users.


I kind of doubt that any majority of TCF members will be participating in this thread. Some, who don't want to change from say a 3TB drive to a 4TB drive, just because their last paring call turned into a days-long nightmare, are likely watching for the results, and might never post anything to help.

Often, I have the easiest paring calls, but sometimes they are nightmarish.

Since drives of larger sizes are coming along, I might be willing to spend the money for all 4TB drives, once they come down a bit more (they are already hitting sale prices which are the same as sale prices when I bought 3TB, but couldn't justify the extra $40-$60 at the time for one more TB, as I have 3 Roamios, and always buy at least 5 drives (which has always been a good move).

If the closest we get is a better chance of smooth pairing, with most of the data being correct, it's still better than nothing. If we can get to the point of better understanding what goes wrong with pairing, that might be reflected by the local data, that's a bonus. If it gets to where pairing data can be backed-up/restored, for Roamios, that will be good for many. If I can get around the paring invalidation mechanism that has a hair-trigger here, I'll be very happy.

I have so many pairing calls to Cox, that they are suspicious of me, and what I'm up to. I've hit the threshold, where I have to beg and argue that they don't need to do a truck-roll, to find a reason for so many pairing calls, and so many that go wrong. I'd have done more to try and help with drive upgrading and this, if I wasn't worried about Cox's worries about the volume of pairing they have a history of. This history will get brought up by them. But, if I ask them to look into the history, they play the "what history?" game...

I think the value of this project will only become apparent once it has been completed. I think I'm the only one asking for it, but believe I'm not the only one who would make use of it.


----------

