What is a satellite TV subscription: CCcam and OScam

If you are asking what a satellite TV subscription is in the context of card sharing — it is not a subscription with the operator. It is access to a remote server that transmits decrypted control words (DCW) for encrypted satellite channels via a TCP connection. Your receiver receives an encrypted transport stream but cannot decrypt it itself — the keys come over the network. You need to understand this mechanism before you start configuring anything at all.

What does "satellite TV subscription" actually mean in the context of card sharing

When a person buys an official subscription from an operator — say, from Tricolor or NTV-Plus — they receive a physical smart card. The card is inserted into a CAM module or directly into the receiver slot, stores viewing rights locally, and decrypts the stream itself. The internet is not needed at all.

In network key exchange, everything is different. The smart card is located on a remote server, and your receiver receives DCW over the network. The entire chain relies on a stable connection with minimal latency. If the internet is lost — the picture freezes.

Official subscription vs key exchange

An official card is a standalone device with a built-in cryptoprocessor. It receives ECM packets (Entitlement Control Messages) directly from the DVB transport stream and returns DCW to the receiver's descrambler — all within one piece of hardware. No network requests, no delays.

In card sharing, the smart card is physically located on a server, sometimes thousands of kilometers away from you. Your receiver sends an ECM request via TCP, the server forwards it to the card, the card calculates the DCW, and the response is sent back. This entire chain must fit within a few hundred milliseconds — otherwise, freezes will occur.

The role of the smart card and CAM module

A CAM module (Conditional Access Module) is essentially an interface between the smart card and the receiver. In the classic version, it is inserted into the CI slot of the tuner. In card sharing, a CAM on your side is not needed: its function is taken over by the software client — softcam.

OScam and CCcam are indeed softcam. They emulate the operation of the CAM module in software, intercept ECM from the transport stream via the dvbapi interface, and forward them to the remote server instead of the local card.

What is a control word (DCW) and why does it change every 10 seconds

DCW (De-Control Word) is an 8-byte key that directly encrypts the video stream. The DVB-CSA standard implies changing this key approximately every 10 seconds (the interval is called the crypto-period). This is done intentionally: even if someone intercepts the current DCW, it will become outdated in a few seconds.

It is precisely because of this cyclicity that a constant connection to the key source is needed. Every ~10 seconds, your softcam must manage to obtain a new DCW before the old one expires. If it doesn't — the screen freezes for a few seconds until the next key arrives.

How CCcam and OScam protocols work internally

Understanding what a satellite TV subscription is on a technical level is impossible without understanding how data moves between the receiver and the server. The chain is short, but each link matters.

The chain ECM request → server → DCW response

The receiver receives the DVB transport stream from the satellite. In this stream, there are encrypted video/audio packets and separate ECM packets — containers with the encrypted DCW of the current crypto-period. The softcam (OScam or CCcam) intercepts ECM via /dev/dvb/adapter0/demux0 using dvbapi.

Then the ECM goes via TCP to the card sharing server. The server forwards it to the smart card through the reader, the card calculates the DCW and sends it back. The softcam sends the DCW to the receiver's descrambler — it finally decrypts the video stream. This entire round-trip must occur faster than the current crypto-period ends.

How CCcam protocol (port 12000) differs from newcamd and cccam over OScam

CCcam is a proprietary binary protocol. The standard port is 12000, although it is set in the config and can be anything. The protocol is quite simple: the client connects, authenticates, and starts sending ECM, receiving DCW in response. It supports reshare out of the box — sharing cards between servers.

newcamd is another protocol, usually operates on ports from 10000 and above. It is older, less flexible, but still encountered. mgcamd is another softcam, works only as a client.

OScam can work both as a server and as a client simultaneously and supports multiple protocols in parallel: cccam, newcamd, cs378x, and others. This is its main advantage — one program covers everything.

EMM requests and rights updates

In addition to ECM, there are EMM packets (Entitlement Management Messages) in the transport stream. They are needed to update rights on the smart card — for example, activating a new channel package or renewing a subscription. EMM is processed only by the real card, so in card sharing, they are also forwarded to the server, but most configurations filter them out to reduce load.

When the operator changes the version of CAS or encryption keys — the old configuration stops working. This is exactly what happens when a channel suddenly disappears after a scheduled update from the operator. The config is not to blame; the card on the server simply needs to receive new rights via EMM.

What are peer, hop, and share in CCcam terminology

Peer is another CCcam server with which your server exchanges cards. Share (or card share) is a virtual card available over the network. Hop is the number of intermediate servers between your receiver and the real physical smart card.

Hop 0 means the card is directly in your receiver or at the direct source. Hop 1 means one intermediate server. Hop 2, 3, 4... — each additional hop adds latency and instability. A server with hop 1–2 will work noticeably more stably than the same stream through 5 hops.

What components are needed for such a subscription to work

Before going further, let's clarify what should be available. Not everything is as obvious as it seems at first glance.

Satellite receiver with Enigma2 support or a card receiver on PC

Most modern card sharing setups are done on receivers running Enigma2 — this is an open operating system for satellite tuners. Dreambox, Vu+, Gigablue, AX/Opticum HD — all of these are Enigma2 devices. You can install OScam and CCcam directly on them.

An alternative is Windows/Linux with a DVB card and a software player like DVBViewer or VDR. On Linux, the softcam is installed via a package manager or manually, on Windows — through special wrappers. But Enigma2 is still more convenient for these tasks.

Softcam: installing OScam or CCcam

On Enigma2, the softcam is installed either through the built-in package manager (opkg) or manually via SSH. OScam is compiled for a specific processor architecture — mipsel for older Dreambox, arm for most modern devices. The binary is placed in /usr/bin/oscam or /usr/local/bin/oscam.

CCcam is a proprietary binary, distributed in ready-to-use form. It is placed there as well. Important: do not run both softcams simultaneously without clear delineation of which one occupies the dvbapi socket (/tmp/camd.socket or similar). A conflict over the socket is one of the most common causes of "unexplained" glitches.

Configuration files: oscam.server, oscam.user, CCcam.cfg

OScam configurations are located in /etc/tuxbox/config/oscam/ or /usr/keys/ — it depends on the firmware image. The main files are:

• oscam.conf — global settings: httpport, logging, dvbapi
• oscam.server — description of readers (where to get keys)
• oscam.user — user accounts for clients, if OScam operates as a server
• oscam.dvbapi — channel mapping and filters for descrambling

For CCcam there is one file: /var/etc/CCcam.cfg or /usr/keys/CCcam.cfg. Client lines look like this:

C: hostname.example.com 12000 myusername mypassword

The letter C means "client". Then, separated by spaces: host, port, login, password. That's it.

Stable internet connection with low ping

Speed is not the main thing here — the traffic of card sharing is minimal, a few kilobytes per second. The main thing is latency and stability. The ping to the server ideally should be below 50–80 ms. With a ping of 200+ ms, problems will start with HD channels, which may have a crypto-period shorter than 10 seconds.

Mobile internet with an unstable signal is a bad choice. Jitter kills the DCW cycle just like high ping.

Basic client setup and connection check

I will show specific examples — not abstract ones, but those that can be adapted to your server.

Writing a C-line in CCcam.cfg

Open /var/etc/CCcam.cfg via SSH or FTP. Add the line:

C: server.example.com 12000 testuser testpass

Save, restart CCcam with the command:

/etc/init.d/CCcam restart

Or through the receiver's control panel. After restarting, CCcam should connect to the server and start receiving shares. The status can be viewed in the log /tmp/CCcam.log — there will be lines like "connected to server" or messages about authentication errors.

Equivalent reader section in oscam.server

For OScam, the same looks different. In the file /etc/tuxbox/config/oscam/oscam.server, add the section:

[reader]

The cccmaxhops parameter limits the cards with what maximum hop to accept — it's reasonable to set it to 2 to avoid long chains of resolutions. After saving, restart OScam:

/etc/init.d/oscam restart

Checking the status through the OScam web interface (port 8888)

This is one of the main advantages of OScam over CCcam — the built-in web interface. For it to work, the [webif] section in the oscam.conf file should contain:

[webif]

Open in a browser http://192.168.1.100:8888 (IP of your receiver). In the Readers tab, we see our reader. Look at the fields: Connected (should be Yes), Cards (number of available cards), EC (number of processed ECM), avg (average response time in milliseconds).

Average response time less than 300 ms — good. 400–600 ms — tolerable for SD, but HD may freeze. More than 800 ms — bad, look for the problem.

Reading logs and connection statuses

OScam log by default is written to /var/log/oscam.log or /tmp/oscam.log. Check it with:

tail -f /var/log/oscam.log

Lines like "reader connected" and "ecm answered" — everything is working. "Connection refused", "authentication failed", "no card for CAID XXXX" — diagnosable errors. If the server responds (status connected), but channels do not open — check CAID and provid in the logs. Most likely, there is a mismatch: the server holds a card from another provider or another package.

How to choose a key source: what to look for from a technical perspective

What satellite TV subscription means in terms of choosing a source — it is primarily a set of technical characteristics, not marketing promises. Here is what really matters.

Stability criteria: uptime and average ECM response time

The ideal ECM response time is up to 300–400 ms. This can be seen directly in the OScam web interface after a few minutes of operation. If the provider offers test access, be sure to check this specifically, rather than just whether the channels open.

Uptime is just as important. A server that reboots every few hours leads to constant log interruptions and a frozen picture at the most inconvenient moment. Ideally, the server's uptime should be measured in weeks.

Local cards vs. reshare

A local card on the server is hop 0 or 1. The server physically holds the smart card in the card reader, reads it, and distributes DCWs to clients. This is the most stable option.

Reshare is when the server itself is a client of another server and redistributes foreign cards further. The hop increases, and the delay accumulates. With hop 4–5, stable operation with HD channels can be expected. Ask the provider if they have local cards for the package you need, or if they are getting them from someone else.

Support for the packages and frequencies you need

Not every server holds cards for all operators. One may have a Viasat card at 4.8°E, another may have Digitürk at 42°E, and a third may have a package on Hotbird 13°E. Specify the exact CAID and provid of the operator you need and check that this CAID appears in the OScam logs when trying to open a channel.

In the logs, it looks something like this: "ECM for CAID 0x0500 provid 0x032830" — this is Viasat/Canal Digitaal. If the server's response does not have the corresponding card, the channel will not open, even if the connection is established.

Warning signs of an unstable server

Look at the logs, not at advertising promises. Frequent lines like "connection lost," "reconnecting," "no answer from server" are clear signs that the server or network is overloaded. Freezes every 10 seconds are classic signs of high hop or large delay: the old DCW has expired, and the new one has not yet arrived.

A fluctuating ECM response time is also a bad sign. If the average is 200 ms, but sometimes it spikes to 1500 ms — these spikes cause freezes. A smooth and predictable response is more important than just a low average value.

And separately about the time on the receiver: some servers implement timestamp verification upon connection. If the system time on the receiver is off by several hours, the server may reject the handshake. Synchronize the time via NTP: in Enigma2, this is done in the system settings or by the command ntpdate pool.ntp.org.