What is a satellite TV subscription and CCcam/OScam

What is a satellite TV subscription in simple terms

If briefly: the satellite broadcasts the same encrypted stream for everyone. The question is not whether you receive the signal — it goes to everyone equally — but whether you have the keys to decrypt it. What a satellite TV subscription is — is essentially the right to receive these keys from the provider.

A receiver without access to the keys sees the transponder, sees the channels in the list, but shows a black screen or the message "signal encrypted." A smart card or CAM module in the CI/CI+ slot is a hardware container that stores rights and generates the necessary keys in real time.

The satellite signal itself is free — it can be received by any dish with a suitable converter. The provider sells not the signal, but access to the decryption system. This is what lies behind the word "subscription."

Official subscription: smart card and CAM module

Standard scheme: the provider issues a smart card (or sells a CAM with a built-in card), you insert it into the receiver, and it decrypts the channels locally. The card stores EMM — control messages through which the provider remotely updates your subscription rights directly from the satellite stream.

CAM module (Conditional Access Module) — is an adapter in the CI or CI+ slot that contains the same logic as the card, but in the form of a separate device. The difference between CI and CI+ is significant: CI+ supports copy protection and pairing with a specific TV, which is important for HD/UHD packages.

What exactly you are paying for: decryption keys, not the signal

The provider broadcasts one encrypted stream. Those who pay receive control words (CW) — pairs of 8-byte keys that change every 7–10 seconds. Without the current CW, the descrambler cannot decode the video stream, even if the signal from the transponder is received perfectly.

In fact, a subscription is a subscriber agreement for the continuous supply of control words. When the subscription ends, the provider stops updating the rights on the card via EMM, and the card stops providing valid CW.

Conditional Access Systems (CAS): Conax, Irdeto, Viaccess, Nagravision

CAS is an encryption standard chosen by the provider. Conax (CAID 0B00) is popular among Scandinavian operators, Irdeto (0600) — among many European ones, Viaccess (0500) is used on Hotbird and Astra, Nagravision (1801, 1810) — by Canal+. Multiple ECMs for several CAS can simultaneously go on one transponder — this is multi-encryption.

For you as a user, this means that the equipment must support the required CAS. A universal CAM with multiple slots solves part of the issue, but not always.

How decryption works: ECM, EMM, and control words

The DVB-S/S2 transport stream is a multiplex of PID packets. Among them are encrypted video/audio packets and two service types: ECM and EMM. The receiver extracts ECM, sends it to the card (or emulator), receives CW back, and passes it to the descrambler. All this happens continuously, every few seconds.

The stream of ECM and EMM in the DVB transport stream

ECM (Entitlement Control Message) — is an encrypted packet, inside which the control word is "hidden." Only a card with the required key for this provider and CAID can decrypt ECM. EMM (Entitlement Management Message) — are commands from the provider addressed to a specific card by its serial number: update rights, extend subscription, block the card.

ECM is the same for all viewers on this channel. EMMs are personalized. This is a fundamental difference: ECM can be "shared" over the network, while EMMs are tied to a specific card.

Control word (CW) and its rotation every 7-10 seconds

CW is two 8-byte keys: even and odd. The descrambler uses them alternately, and the card provides the next pair in advance while the current one is still active. If the next CW does not arrive on time — the video freezes. Hence the requirement for ECM response time: in a normal scheme, it is 50–200 ms, when sharing over the internet — preferably no more than 300–400 ms.

Providers can shorten the rotation interval to 3–5 seconds for enhanced protection. This directly impacts the stability of network sharing — the server simply does not have enough time to deliver the CW to the client before the next change.

The role of CAID, provider ID, and SID in addressing

CAID (CA System ID) — is a four-digit HEX identifier of the encryption system. Provider ID — is the identifier of a specific provider within the CAS. SID (Service ID) — is the number of a specific channel in the multiplex. Together they form an addressing trio, by which OScam/CCcam directs ECM to the correct reader.

In the configs, it looks like this:caid = 0500 +ident = 0500:023800 (where 023800 is the provider ID) + SID filters if necessary. Without the correct trio, the reader will either not respond or return an incorrect CW.

What is cardsharing and what does CCcam and OScam have to do with it

Cardsharing is a logical continuation of the ECM/CW architecture: since ECM is the same for everyone, it can be sent to a server with the card over the network, and CW can be received back. Physically, there is one card — on the server. There can be several clients who decrypt channels through it.

The idea of card sharing: one card — decryption of ECM over the network

The client receiver does not send ECM to the physical card — it sends it via TCP to a remote server. The server receives ECM, passes it to a local smart card (or emulator), receives CW, and returns it to the client. The client passes CW to the descrambler — the picture appears. Network delay here is a key parameter.

CCcam as a protocol and software

CCcam is both a daemon program for Linux receivers (especially popular on Dreambox) and a protocol for exchanging CW. By default, it operates on TCP port 12000. The client config is a lineC:, the server config is a lineF: and local cards throughB: orF:.

CCcam has long been the de facto standard. Simple syntax, wide hardware support. But the architecture is monolithic — one process, limited flexibility in working with multiple CAS and readers.

OScam as a modern alternative and its modularity

OScam (OSCam) — open-source daemon with a modular architecture. The separation into reader (connection to the card or emulator) and user/account (clients) provides flexibility unattainable in CCcam. Supports multiple protocols simultaneously: CCcam, newcamd, camd35, gbox, and others. The web interface runs on port 8888 by default.

For complex configurations — multiple cards, multiple CAIDs, clients on different protocols — OScam is the obvious choice. The only downside: the entry threshold is higher, the config is multi-file.

newcamd, mgcamd, and other exchange protocols

newcamd is an older protocol than CCcam, usually runs on port 15000 (configurable). Supported by most receivers and emulators. mgcamd is a client emulator for Linux receivers, capable of working with both local keys (SoftCam.Key) and remote servers via newcamd/CCcam protocol. Often used on STBs with Enigma2 when OScam is excessive.

Client-server architecture: key files and ports

Understanding what a subscription to satellite TV is at a marketing level is one thing. Understanding where the configs are and how to read the logs is another matter. Let's break down the real file structure.

CCcam: /var/etc/CCcam.cfg and lines F:/C:

The main CCcam config on an Enigma2 box:/var/etc/CCcam.cfg. On some systems, the path/etc/CCcam.cfg. The structure is simple:

• C: hostname 12000 username password — client line (connection to a remote server)
• F: username password — account for incoming connections (when your box itself is the server)
• B: /dev/sci0 [reader options] — local card reader

Restart after changes:/etc/init.d/CCcam restart or through a plugin on the box. Check logs in/tmp/CCcam.log or viatail -f /tmp/CCcam.log.

OScam: oscam.conf, oscam.server, oscam.user

OScam breaks the configuration into several files in the directory/etc/oscam/:

• oscam.conf — global settings and sections[global],[webif],[newcamd],[cccam]
• oscam.server — description of readers (physical cards, card readers, remote servers)
• oscam.user — client accounts
• oscam.services — grouping of channels by SID for filtering

Example of the reader section inoscam.server:

[reader]

The parametermhz specifies the operating frequency of the card reader — for some cards, an incorrect value causes reading errors even with physically functioning hardware.

Standard ports: 12000 (CCcam), 8888 (webif OScam)

TCP 12000 — CCcam protocol (incoming client connections and outgoing to the upstream server). TCP 8888 — web interface OScam, available athttp://ip:8888. The newcamd port is specified inoscam.conf in the section[newcamd], often defaulting to 15000. All these ports must be open in the firewall and forwarded through NAT if the server is behind a router.

Typical error: the client "sees" the server via ICMP (ping passes), but TCP 12000 is blocked by the firewall or not forwarded. The line does not come up, in the CCcam logs — "connect failed" or connection timeout.

Checking the connection and reading logs

The OScam web interface on port 8888 shows the status of each reader, current ECM time, number of successful/unsuccessful requests, and a list of active clients. This is the first place for diagnostics.

For CCcam:tail -f /tmp/CCcam.log | grep -E "ECM|CW|connect" — shows a live picture. Lines with "ECM time" and "cache" help understand where CW is coming from and how fast. If ECM time is consistently above 500 ms — look for problems in the network or reader overload.

Official subscription versus sharing: differences and risks

Here without illusions. An official provider subscription is a physical card, local decryption, guaranteed stability, and complete legality. For each receiver — a separate card, a separate fee. Network sharing provides flexibility but adds a variable in the form of internet connection quality and server reliability.

Stability, freeze, and ECM response time

An official card in the receiver slot responds to ECM in 10–50 ms — the local bus works quickly. Network sharing adds network latency: 50 ms to the server, processing, 50 ms back — already 150–200 ms minimum. With a normal 10-second CW rotation, this is not critical. But if the rotation is accelerated or a packet is lost — freeze is inevitable.

Frequent causes of freeze during active sharing:

• High ECM time due to geographical distance from the server
• Overloaded reader — too many clients on one card
• Invalid CAID or ident in the config — OScam cannot direct ECM to the correct reader
• Conflict of two readers with the same CAID without priority settings throughgroup andcaid in oscam.server

Legal aspects and user responsibility

Directly: legislation in different countries interprets cardsharing differently. In several EU countries, it is classified as a violation of copyright law or unauthorized access to paid services. A user receiving content through an unlicensed sharing server bears legal responsibility under the laws of their country.

This is not a checkbox section. Understand the legal side on your own, applicable to your jurisdiction, before setting anything up.

Why HD/UHD packages and BISS channels behave differently

Some HD and most UHD packages use chipset pairing — binding the card to a specific receiver chipset at the EMM level. The card only issues CW to the receiver that has gone through the pairing procedure. Network sharing is technically impossible here: the server with the card receives ECM from the client receiver, the card rejects it because the chipset ID does not match the registered one.

BISS (Basic Interoperable Scrambling System) — is a completely different story. This is not CAS in the classical sense: one static key per channel, no ECM/EMM, no subscription. BISS is used for broadcasts (sports, events) and SNG feeds. Keys do not change automatically but are updated manually via SoftCam.Key or similar. When the organizer changes the BISS key, all saved recordings become useless until the key file is updated.

Understanding what a subscription to satellite TV is in the context of these various technologies is important to avoid wasting time setting up sharing for channels where it fundamentally will not work.

How to choose an access provider: technical criteria

Without naming specific services — here’s what really matters when choosing:

• Declared and actual uptime — ask users on forums, do not trust advertising figures
• Average ECM time — a normal indicator is up to 300 ms, anything above 500 ms will cause periodic freezes
• Support for the necessary CAID and ident — make sure the card works specifically with your package of channels
• Backup lines — if the main server goes down, the client automatically switches to the backup
• Possibility of a trial period — a normal provider gives 24–48 hours for testing