What is a satellite TV subscription: CCcam/OScam and card sharing from the inside

What is a satellite TV subscription and where does card sharing fit in

If you want to understand what a satellite TV subscription is in a technical sense — let's start with the basics. The operator encrypts their signal. To watch channels, you need a key. This key resides on a smart card that the operator issues along with the subscription. The card is inserted into a CAM module or directly into the receiver — and the receiver decrypts the stream in real-time.

This is the classic scheme: one contract, one card, one TV. You pay the operator once a month, the card receives updated rights through EMM messages, and the channels open. Everything works locally — no internet is needed.

Card sharing is a different story. Here, one physical card is on a server, and its "responses" are received by several clients simultaneously over the network. Technically, this is the distribution of control words (control words, DCW) via special protocols. This is what the entire world of CCcam and OScam is built around.

Official subscription from the operator and smart card

When you purchase an official subscription from a satellite operator — Viasat, Tricolor, NTV+, or anyone else — you receive a physical smart card of the ISO 7816 standard. Inside it are recorded decryption keys and rights to view specific channel packages.

The receiver receives encrypted ECM packets from the satellite stream, transmits them to the card via the CI/CI+ interface, the card decrypts them and returns the control word. The receiver applies the DCW to the stream — and you see the picture. All this happens in fractions of a second, locally, without a network.

The card is tied to a specific operator and a specific conditional access system (CAS). Irdeto, Nagravision, Viaccess, Conax, Videoguard — each has its own CAID and its own cryptography. Without the card — there is no decryption.

What is card sharing in simple words

Card sharing removes the requirement of "the card being next to the receiver." The card is located on a server somewhere on the network. Your receiver sends an ECM request to this server via TCP. The server processes the request through the real card, receives the control word, and returns it to the client. The receiver decrypts the stream.

The delay must be minimal — the control word has a lifespan of about 10 seconds. If you don't receive the new DCW in time — the picture freezes or breaks up. That's why the ping to the server is so important.

This is why protocols CCcam and newcamd were created. They describe how exactly the client and server exchange ECM requests and DCW responses over TCP.

How CCcam and OScam differ from a regular subscription

An official subscription and card sharing are two different ways to obtain the same control word. In the first case, the card is in your receiver. In the second — somewhere on the network, and you receive the already decrypted DCW via the protocol.

CCcam is a protocol and at the same time the name of a specific server/client program. OScam is a more flexible open-source emulator that can work with both local cards and network sources, and supports several protocols simultaneously: CCcam, newcamd, camd3, gbox, and others.

In practice today, most setups are based on OScam. CCcam is still encountered, especially in older configs, but OScam is more flexible, more stable in logging, and better diagnosed through the web interface.

How key distribution (DCW and ECM) technically works

This part is something that is almost nowhere to be found in Russian-language materials. Everyone writes "card sharing is the distribution of keys," but no one explains the cycle as a whole. Let's go through it step by step.

What are ECM, EMM, and control word (DCW)

The satellite stream contains several types of packets. The payload is encrypted video and audio. Along with it come ECM (Entitlement Control Message) — small packets that contain the encrypted control word. And EMM (Entitlement Management Message) — messages for updating rights on the card.

ECM is encrypted with keys that are only on the smart card. The receiver cannot decrypt ECM by itself — it sends it to the card. The card decrypts and returns the DCW — 16 bytes, two keys of 8 bytes (even and odd). The receiver applies the DCW to the stream via the CSA algorithm and receives unencrypted video.

Every ~10 seconds, the operator changes the DCW. A new ECM with a new encrypted control word appears in the stream. The cycle repeats. If the client does not manage to receive the new DCW — freeze.

EMM works differently: it updates the rights of the card. When you pay for the subscription, the operator sends an EMM via satellite that "activates" the necessary channel packages on the card. Without EMM, the card may know the key but not have rights — the channel will remain black.

The role of CAID, provider ID, and SID

Each conditional access system has its own identifier — CAID (Conditional Access ID). For example: 0x0500 — Viaccess, 0x0B00 — Conax, 0x0604 — Irdeto 2, 0x1810 — Nagravision 3, 0x0D00 — Cryptoworks. These are hexadecimal numbers, and they are important for configuration.

Provider ID is the identifier of a specific operator within the system. Sometimes the card supports the required CAID, but the provider ID in the config does not match — and the channel does not open. This is one of the most common reasons for a "black screen" with a correctly connected reader.

SID (Service ID) — the identifier of a specific channel in the stream. OScam can filter by SID — for example, allowing the client only certain channels. This is useful for fine-tuning access rights in oscam.user.

The path of the packet: receiver → server → card → response

The client receiver receives the satellite stream. It sees the ECM. Through a plugin (for example, oscam as a client or CCcam client), it sends the ECM via TCP to the server.

The server receives the request, checks its readers — which one has a card with the required CAID. It passes the ECM to the physical card through the reader (USB card reader, built-in slot). The card returns the DCW. The server sends the DCW back to the client over the same TCP connection.

The client receives the DCW, applies it to the stream. The picture opens. This takes 50-200 ms with normal ping. The control word has a buffer — 10 seconds — but with a poor connection, this buffer is quickly consumed.

Protocols CCcam and OScam: ports and exchange principles

Let's break down the protocols specifically, with port numbers and formats — this is what is really needed during setup.

Protocol CCcam (port 12000) and newcamd

CCcam operates over TCP, the standard port is 12000. The protocol is binary, proprietary. The handshake begins with the exchange of random data for hashing, then the client sends the login and password (SHA1). After successful authentication, the client receives a list of server cards and can send ECM requests.

Newcamd (also known as newcs) — another protocol, usually operates on ports 15000 and above. It uses DES encryption for exchange. The connection line format in the client's config:N: hostname port username password deskey. The DES key is 28 hex characters, and it needs to be obtained from the server owner.

Both protocols are still widely used. CCcam is slightly easier for basic setup — login, password, port. Newcamd is a bit more complex due to the DES key, but it works better through NAT in some configurations.

An important point: if port 12000 is closed on the router or you are behind double NAT — the client will not connect. You need to either forward the port or set up a VPN. Double NAT is a common reason why the client "sees the server" by ping, but the connection via CCcam does not establish.

OScam as a modern alternative

OScam is an open-source project that replaces both the CCcam server and client, and works with local cards. The main advantage is that it can simultaneously accept connections via the CCcam protocol from clients and connect to external sources via newcamd or CCcam. This means one OScam server can combine several card sources and distribute them to clients via multiple protocols.

The OScam web interface opens on httpport 8888 (by default). It shows in real-time: which readers are connected, how many ECM requests have been processed, response time, and the status of each client. This makes diagnostics much more convenient than parsing text logs blindly.

On Enigma2 receivers, OScam runs as a plugin and works both as a client (receiving DCW from the server) and as a local emulator for the card in the receiver's slot.

cardserver, reader, and user — who is who

In OScam terminology, there are three key roles. Reader is the card source. This can be a physical card in a USB reader, or a network connection to another server via CCcam/newcamd. The reader is described in the fileoscam.server.

User is the client that connects to your OScam server. Its parameters (login, password, access group, limits) are described inoscam.user. The user can only receive DCW through readers that are part of their access group.

Cardserver is OScam itself in server mode. It receives ECM from users, routes requests to the appropriate reader by CAID and group, obtains DCW, and sends it back to the client. All of this happens within a single oscam process.

Basic structure of OScam server configuration

The paths to the configs depend on the distribution and hardware. On receivers with Enigma2, it is most often/etc/tuxbox/config/oscam/ or/var/etc/oscam/. On a Linux server (Debian/Ubuntu) — usually/etc/oscam/. On some older firmware OE1.6 — the path may be/usr/local/etc/oscam/. Check the documentation for your firmware.

Files oscam.conf, oscam.server, oscam.user

oscam.conf — the main config. It contains global settings for the daemon: logging level, path to the log file, web interface settings. The minimal working version of the [global] section:

[global]

oscam.server describes readers — that is, card sources. For a network source via the CCcam protocol, it looks like this:

[reader]

oscam.user describes the clients of your server. Each client is a separate [account] section:

[account]

The parametergroup in oscam.server and oscam.user must match — otherwise, the client will connect, but ECM requests will not be routed to the reader. This is one of the most common mistakes during the initial setup.

Paths to configs and web interface (httpport)

The OScam web interface listens on port 8888 by default. Open your browser tohttp://192.168.1.X:8888 (the IP of your receiver or server) and see the complete picture: the status of each reader, a list of connected clients, and a real-time ECM request graph.

On older Enigma2 firmware (OE1.6, Image 2.x), there is sometimes a problem: oscam is compiled without web interface support. In this case, all diagnostics are only through the log file. If the web interface does not open, check that the option is compiled in oscamWITH_WEBIF — this is visible in the version line when starting oscam with the flag-V.

The log file is located at oscam.conf (/tmp/oscam.log or/var/log/oscam.log) at levelloglevel = 4 logs all ECM requests and responses. Level 5 — full debug, generates huge files but provides maximum information for diagnostics.

A minimal working example of line C: and N:

Line C: is the client connection format in the CCcam config (file/etc/CCcam.cfg). Structure:

C: hostname port username password

Line N: is for the newcamd protocol:

N: hostname port username password 01 02 03 04 05 06 07 08 09 10 11 12 13 14

The last 14 pairs of hex digits are the DES key. It must match what is configured on the server side. An incorrect DES key = inability to decrypt the handshake = connection is not established, although the TCP port is open.

Important: do not insert extra spaces or invisible characters after the password in the config — CCcam is sensitive to the string format and silently ignores incorrect entries without errors in the log.

Typical problems and their diagnostics

Most card sharing problems fall into three categories: the channel does not open at all, the channel opens but freezes, or the reader is connected by status but nothing works. Let's break down each.

The channel does not open: ECM timeout and no card

The first thing to check is the OScam web interface, the Readers tab. The status should be CONNECTED. If CONNECTING or OFF — the problem is with the connection to the source: incorrect host/port, closed firewall, incorrect login/password.

If the reader is CONNECTED but the channel does not open — check the log for the words "ECM timeout" or "no card". ECM timeout means that the request was sent, but the response did not arrive in time. Reasons: high ping (more than 150-200 ms), overloaded server, or CAID/provider ID on the server does not match what is needed for this channel.

"no card" in the log — the server accepted the request, but it does not have a card with the required CAID. Check thecaid parameter in oscam.server — it must match the CAID of the channel. The CAID of a specific channel can be viewed in the OScam web interface, Services tab, or in the channel information in the receiver's EPG.

A separate situation: the card supports CAID, but the provider ID is not correct. In oscam.server, you can explicitly specifyproviders = 000000 with the required provider ID. Without this, the server may refuse to process ECM for this provider, even if the CAID matches.

FREEZE and picture breakup due to ping

The channel opens, but after a few seconds it freezes — classic DCW timing problem. The control word changes every ~10 seconds. If the new DCW arrives with a delay of more than these 10 seconds — freeze.

Ping over 200 ms to the source — already a risk zone for HD channels. SD channels sometimes tolerate 300 ms because their stream is less critical to timing accuracy. But HD with high bitrate at ping 250+ ms will freeze regularly.

It's checked simply: ping the host from oscam.server. If the ping is unstable (jitter), it is worse than a fixed delay. Jitter of 50-100 ms with an average ping of 80 ms = periodic freezes that are hard to catch.

Another reason for freeze — the operator changed the keys (key change). The old distribution stopped correctly opening the package, DCWs arrive, but they are incorrect. The picture either breaks into artifacts or freezes. In this case, you need to wait for the card update on the server side.

Reading OScam logs and reader status (CONNECTED/OFF)

The fastest way to diagnose is to tail the log in real time:

tail -f /tmp/oscam.log

Under normal operation, you will see lines like:

2026/06/18 12:34:56 reader my_cccam_source (CONNECTED) [cccam] ECM SID 1234 CAID 0500 OK (72ms)

72 ms — response time. Everything up to 150 ms is good. 150-250 ms is acceptable for SD, risky for HD. Above 300 ms — look for another source or check the network.

If you see in the log:account client1 FORBIDDEN (group) — it means the user in oscam.user has a group that no reader has. Add a matching group in oscam.server — the problem is solved. This is the very group conflict that is easy to forget during the initial setup.

How to choose a sharing source: what to look for

There will be no names of specific services here. But the criteria are specific, and you should know them before registering anywhere.

Criteria: stability, ping, uptime

Ping is the first filter. Up to 100 ms is good, up to 150 ms is acceptable, above 200 ms — there are already problems for HD channels. A geographically closer server almost always wins. A European server for watching European packages is a reasonable choice.

Uptime is more important than price. A server with 99% uptime and 80 ms ping is better than a cheap one with 90% uptime and 50 ms ping. Half an hour of downtime a day means several evenings a month without a signal during prime time.

Response speed to ECM is a separate parameter. You can have low ping to the server, but if the card on the server responds slowly (overloaded reader, weak hardware), the total ECM time will be high. Good sources provide ECM responses of less than 100 ms in total.

Support for required CAID and packages

Before taking a trial period from any source — make a list of required CAID. Open the channel on the receiver, check the signal information: there will be CAID and SID. Write it down. Then compare it with what the source supports.

Sometimes a source claims support for CAID 0x0500 (Viaccess), but the specific provider ID of the operator is not listed there. Technically, the card exists — but your channels do not open. Clarify not just the CAID, but the specific package and provider ID.

Key change by the operator is a reality. When the operator changes encryption keys, old shares temporarily stop working. A good source updates quickly — within a few hours. A slow one can "hang" for days.

Local card vs network source

If you have an official operator subscription and a physical smart card — you can set up OScam with a local reader. The card is inserted into a USB card reader or into the receiver's slot. OScam sees it as a reader with typeprotocol = internal orprotocol = mouse depending on the interface.

The advantage of a local card is obvious: zero dependence on external connection, maximum response speed (ECM is processed locally in 5-20 ms), no risks of downtime from a third-party server. The downside is that the card is tied to a specific operator and package.

A network source provides flexibility: you can connect several readers with different CAID and cover packages from different operators through one OScam instance. But here, dependence on the quality of the connection and the reliability of the external server arises.