Subscription to satellite TV and CCcam: how it works

What is a subscription to satellite TV in simple terms

In short: a subscription to satellite TV is a paid right to decrypt closed channels of the operator. The signal is available to everyone, but without the key, it turns into garbage. The key is stored on the subscriber's smart card — a small chip that is inserted into the receiver.

The operator sells not the signal itself, but the right to decrypt it. This is fundamental. The signal is the same for everyone — both for the paying subscriber and for the neighbor without a card. The only difference is the presence of a valid key.

Official subscription of the operator and subscriber card

With an official subscription, the operator sends a smart card that contains the rights to a package of channels. The card is inserted into a CI module or the receiver's slot. All decryption occurs locally — the receiver communicates with the card via the standard ISO 7816 protocol.

The rights on the card are updated through so-called EMM messages, which the operator constantly transmits in the satellite stream. If the subscription is extended — within a few minutes, the card will receive new rights directly from the air, without calls to support.

Conditional Access System (CAS) and channel encryption

CAS (Conditional Access System) is a combination of software and hardware that manages access to content. The most common systems are: Viaccess, Nagravision, Irdeto, Conax, BISS. Each has its own CAID — a numerical identifier that the receiver uses to understand which system the channel is using.

The channel is encrypted on the operator's side using a control word (CW) — an 8-byte key. This key changes approximately every 5–10 seconds. The encrypted stream along with service packets ECM (Entitlement Control Message) is sent to the satellite and from there to all receivers in the coverage area.

Where the concept of "sharing" a subscription comes from

This is where it beginscard sharing. Instead of each subscriber having their own physical card, one real card connects to the server, and several client receivers receive the control word from it over the network. The video stream is not transmitted anywhere — only a tiny key (16 bytes) over TCP.

This understanding is important from a technical point of view: sharing is not streaming, not IPTV, and not a pirate copy of the signal. It is the exchange of decryption keys in real time.

How decryption works: ECM, EMM, and control word

Let's break down the chain in more detail, because this is where most newcomers get lost. When the receiver is tuned to an encrypted channel, it sees several types of packets in the transport stream (MPEG-TS): the video stream itself (encrypted) and service PIDs with ECM and EMM.

ECM stream and control word (CW) request

ECM is an encrypted container that hides the current control word inside. Only a smart card with rights to this channel can decrypt ECM, because asymmetric encryption is used inside with keys embedded in the card at issuance.

The receiver extracts ECM from the stream and sends it to the card. The card checks the rights, decrypts ECM, and returns the control word. The receiver applies the CW to the video stream — and the picture appears on the screen. The entire cycle takes milliseconds.

In sharing, the receiver sends ECM not to the local card slot, but over the network to the CCcam/OScam server. There, the card decrypts ECM, and the server returns the ready CW to the client. The client receiver uses it just as if the card were physically inserted.

The role of EMM and rights updates on the card

EMM (Entitlement Management Message) is a separate type of packets addressed to a specific card by its unique ID. Through EMM, the operator delivers rights updates to the card: connecting new channels, extending the subscription, blocking compromised cards.

In the sharing scheme, EMM is also important: if the server does not pass EMM to the card (or the card does not receive them from the air), the rights on it gradually become outdated. This is one of the reasons why the source may "die" after a few months — the card simply did not receive an extension.

In OScam, there is a setting for EMM transmission through the parameteremmcacheand filters in oscam.server. It is worth monitoring this if you are using your own card on the server.

What exactly is transmitted in sharing and what is not

Only the control word — 16 bytes for each key change, that is, approximately every 10 seconds. No video stream is sent over the network. The client receives the satellite signal independently, with their antenna and receiver — just like an ordinary subscriber.

This explains why even a slow internet connection is sufficient for sharing: the traffic is minimal, latency is critical. If the ping to the server is more than 200–300 ms, the CW may arrive late — the channel will start to freeze exactly at the moment of key change.

CCcam and OScam: what is the difference between the protocols

CCcam is historically the first popular daemon for sharing, which appeared in the 2000s. OScam is a newer open-source project that is now the de facto standard for serious installations. Both solve the same problem, but approach it differently.

CCcam protocol: the principle of newcamd/cccam exchange

CCcam uses its own binary protocol over TCP. The client connects to the server, authenticates with a username/password, and then there is a constant exchange of ECM requests and CW responses between them.

The client configuration in CCcam looks like a C: line in the file/etc/CCcam.cfg:

C: hostname.example.com 12000 username password

Fields in order: server host, port (default is TCP 12000), username, password. One line — one line to one server. No extra logic: CCcam is simple to set up, but lacks management capabilities for priorities and filtering.

The newcamd protocol is also supported — it differs slightly in packet structure and by default uses a different port (usually 15000–15010 depending on the server config). Newcamd is slightly older and is found in some receivers as a built-in client.

OScam as a modern alternative with a flexible config

OScam is a daemon with a modular architecture. It can be both a server and a client at the same time, supports dozens of protocols (CCcam, newcamd, camd3, gbox, and others), and has a powerful filtering system by CAID, provider ID, and SID.

The configuration is split into several files. The main one isoscam.conf, where global parameters, web interface, and logging are set. Readers (sources of cards or lines) are described inoscam.server. Users are inoscam.user.

A typical reader inoscam.server for a CCcam line:

[reader]

The parametercaid is critical here — it determines which requests will go through this reader. If the CAID does not match what the channel is broadcasting, the reader is simply ignored for that request.

Ports and network interaction (TCP 12000, newcamd)

Standard ports that are actually found in configs:

• CCcam protocol: TCP 12000 (de facto standard, although the server can use any)
• Newcamd: TCP 15000–15010 (the range depends on the server config)
• OScam web interface: TCP 8888 (set by thehttpport parameter in oscam.conf)
• OScam camd3: TCP 15000 (if this protocol is used)

If the server is behind NAT, port forwarding is needed. A common situation occurs: in the OScam log, the client's connection is visible, but the channel does not open — this is precisely a NAT issue on the server side or an incorrect external IP in the client's config.

Official subscription against card sharing: legal and technical nuances

This needs to be discussed honestly. An official subscription to satellite TV is a contract with the operator, a physical card, technical support, and guaranteed quality.Card sharing via CCcam/OScam — technically an analogous result, but a different legal story.

Legal scenarios: test benches and own cards

CCcam and OScam themselves are legal software. Using them to manage your own legally acquired cards, testing receivers in a lab, or studying CAS protocols raises no questions. Many system administrators deploy a local OScam server so that one card works on several receivers in one apartment — this is a gray area in most jurisdictions, but technically this is exactly what this entire stack was built for.

The responsibility for the legality of a specific CW source lies with the user. This is not a disclaimer on our part — it is a fact: only you know where you get the card or line from.

Technical risks of an unstable CW source

This is where the official subscription wins without question. If the operator changes the CAS version or starts rotating keys more frequently — the official card adapts automatically through EMM. A sharing source can fail at any moment without warning.

High ECM time — the first symptom of a problem. If the response to the ECM request comes in over 800 ms instead of the normal 50–150 ms, the channel will start freezing every 10 seconds exactly at the moment of CW change. This is not a receiver problem — it is a problem with the source or the network between you and the server.

Another risk: CAID mismatch. The same package of channels from different operators or on different satellites may have different CAIDs. A source that works great for one transponder may be useless for another — even if the package name is the same.

Criteria for evaluating a subscription source (without specific names)

What to look for when choosing a sharing server:

• Ping to the server — ideally up to 50 ms, acceptable up to 150 ms. Higher — freezes are guaranteed.
• Uptime — check if there is public statistics or availability history. A server with 95% uptime means 36 hours of downtime per month.
• Support for the required CAID — specify the specific CAID and provider ID, not just the package name.
• ECM time in real conditions — a good server delivers CW in 50–100 ms.
• Behavior when changing CAS by the operator — how quickly the source updates after the operator switches to a new system.

Basic functionality check of the subscription

So, CCcam or OScam is configured, the line is added, but the channel still does not open. Let's troubleshoot step by step.

Viewing line status in the OScam web interface

OScam has a built-in web interface, which is available athttp://[receiver-IP]:8888. The port is set inoscam.conf:

[webif]

In the sectionReaders all configured readers and their status are visible: CONNECTED, DISCONNECTED, CARDOK. If the reader shows CONNECTED but the card is not read — check the fieldCAID. If it is empty or does not match the expected, the reader is connected but cannot service your requests.

The tabUsers shows active clients. The fieldECM time — average response time in milliseconds. This is your main indicator of line health.

Reading logs and diagnostics by CAID/ECM time

OScam logs are written to a file, the path is set in oscam.conf with the parameterlogfile. A typical path is/var/log/oscam/oscam.log or/tmp/oscam.log on receivers with limited flash memory.

View log in real time:

tail -f /var/log/oscam/oscam.log

What to look for in the log when having channel issues:

• no matching reader found — no reader with the required CAID. Check the parametercaid in oscam.server.
• card not inserted — the reader is connected, but the card is not responding or not authorized.
• ECM rejected — the server received the ECM, but the card rejected it. Most often — no rights for this channel.
• not found (0 ms) — the request was sent, but no reader returned CW.

If the log shows that the request is going to the reader, but ECM time keeps increasing (500 ms, 800 ms, 1200 ms), — this is a network issue between you and the server, or the server itself is overloaded.

What typical decryption error codes mean

Conflict of multiple readers for one CAID — a separate story. If two readers with the same CAID are specified in oscam.server and both are in the same group, OScam will try them by priority. The priority is set by the parameterpriority (a lower number = higher priority). If priorities are not set, the behavior is unpredictable.

Another nuance that actually occurs: the receiver firmware stores configs in a non-standard directory. On Enigma2 receivers, this is usually/etc/tuxbox/config/oscam/, but some builds use/usr/keys/ or/etc/oscam/. If you edit files in one place, but OScam reads from another — changes will not apply. Check where OScam is running from:

ps aux | grep oscam

The parameter-c in the command line will show the actual config directory.

And finally: if the operator has switched to a new version of CAS or started using more frequent CW changes (for example, every 3–4 seconds instead of 10), the old source simply cannot deliver the keys in time. This cannot be fixed on the client side — only if the source updates.