Satellite TV via sharing: what it is and how it works

If you are hearing the term "card sharing" for the first time and want to understand what a subscription to satellite TV via sharing is — this article is just for you. Not because there will be "do it in five minutes" instructions here, but because without understanding the mechanics, you won't be able to properly set up the system and even more so diagnose problems. Let's break down the principle from scratch: from the ECM request to the lines in the OScam log.

What is a subscription to satellite TV via card sharing

Formally, a subscription to satellite TV via sharing is network access to the decryption of an encoded satellite stream through a remote server, where the operator's original smart card is located. Your antenna receives the signal as usual. The only difference is where the decryption takes place.

With an official subscription, the card is in your receiver and decrypts the stream locally. With sharing, the card is on a server somewhere on the network, and your receiver only receives keys from it via the internet. The signal from the satellite is still caught by your dish, no video is transmitted over the network.

Official operator subscription vs card sharing

With an official subscription, the operator provides you with a smart card, which is inserted into the CI slot or directly into the receiver. Everything is decrypted directly in the hardware, no internet is needed. This is the only completely legal way to watch paid channels.

Card sharing is a different story. One person with a card services several clients over the network. From the operator's point of view, the card is used by one subscriber, but in reality, the decryption keys go to dozens of clients. Legally, this is a violation of the card's terms of use and the legislation of most countries.

The role of the smart card and conditional access system (CAS)

The encoded satellite stream operates through a conditional access system — CAS (Conditional Access System). This can be Viaccess, Nagravision, Irdeto, Conax, or another standard. The card contains cryptographic keys of a specific operator and can decrypt ECM packets that are transmitted along with the video stream.

Without a card, the receiver sees the stream, but cannot play it — it is just noisy data. CAS is the lock, the card is the key.

How local viewing differs from network sharing

In local viewing, the decryption cycle is entirely in the receiver: card → CAS module → descrambler → video. The delay is in milliseconds. In sharing, a network hop is added: the request goes to the server, where the card decrypts it, and the CW returns to the client. All this takes from 100 ms to 2 seconds — depending on the ping and server load.

How key exchange works technically: ECM and CW

Here is how the decryption cycle looks in detail. The receiver receives the encoded transport stream (MPEG-TS). In this stream, alongside video and audio, there are ECM packets — these are encrypted messages that contain the control word for the given time window.

The receiver takes the ECM and sends it to the server via the CCcam or newcamd protocol. The server sends the packet to the physical smart card in the reader, the card decrypts it and returns the CW — 16 bytes of the key. These 16 bytes fly back to the client, and the receiver descrambles the stream.

What is an ECM request and control word

ECM (Entitlement Control Message) is an encrypted packet that is transmitted by the operator along with the video. Without the operator's keys, it cannot be decrypted. The control word is the descrambling key, which changes approximately every 10 seconds.

That is why the connection must be stable constantly, not just when changing channels. If a new CW does not arrive within 10 seconds — the stream freezes. Hence the freezes with an unstable connection.

The path of the packet from the receiver to the server and back

The scheme is as follows: receiver → router → internet → server → smart card in the reader → CW → back through the same chain. Each link adds delay. Phoenix/SmartReader USB readers process the request in about 50–150 ms. Plus the network. Plus the queue for the card if many clients are connected to it.

EMM (Entitlement Management Message) is another type of packet, they manage the rights of the card itself. For client sharing, they are less important, but the server must accept them correctly, otherwise the card will be deactivated after the next update by the operator.

Delay (zapping time) and why it occurs

The typical channel switching time in sharing is 0.3–2 seconds. This is normal. Above 3 seconds — it is already a problem. The main reasons for the delay: ping to the server (anything above 100 ms is noticeable), ECM time of the card itself (some operators' cards respond longer than 500 ms), server overload.

Another factor is the limit of ECM per second for the card. If you switch channels quickly, the card starts to reject requests. OScam logs this asECM rejected orECM too slow.

Protocols CCcam and OScam: what is the difference

CCcam and OScam are not just different software, they are different approaches to the same task. CCcam appeared earlier, was proprietary, but its protocol was reverse-engineered over time. OScam is completely open, developed by the community with open source.

CCcam: proprietary protocol and its features

CCcam listens on port 12000 by default. The protocol is binary, session-based, with hash-based encryption. The server config is/etc/CCcam.cfg, where readers and user lines are specified (F:-lines). On the client — the lineC:.

Among the downsides — logging in CCcam is weak compared to OScam. It's harder to understand what exactly is happening with the card and requests. For debugging, you will either have to set verbose logging or switch to OScam.

OScam: open softcam, flexibility, and logging

OScam supports several protocols: cccam (compatible with CCcam clients), newcamd, cs378x. The web interface runs on port 8888 by default — this is one of the most convenient features in OScam, allowing you to see all requests, reader status, and card response time in real time.

The configuration is split into several files:oscam.conf (global settings),oscam.server (readers and remote servers),oscam.user (client accounts). This is more convenient than the monolithic CCcam.cfg, although it may seem more complicated for a beginner at first.

When MGcamd and newcamd are needed

MGcamd is a lightweight client that can work with multiple protocols simultaneously. It is convenient on weak hardware when OScam seems heavy. Newcamd (port 15000) is a protocol for direct communication with the card or emulation. If the server provides newcamd, the client is configured accordingly through[reader] section inoscam.server with the parameterprotocol = newcamd.

cs378x is a protocol from the authors of CCcam, works over TCP, port 15050. It is less common, but some servers support it.

Standard ports and network requirements

Protocol	Default port	Purpose
CCcam	12000	Client-server CW exchange
newcamd	15000	Direct communication with the card
OScam webif	8888	Monitoring web interface
cs378x	15050	Alternative CCcam protocol
dvbapi	9000	Local IPTV/decryption

All these ports need to be forwarded on the router if the server is behind NAT. Without forwarding, external clients will not be able to reach it.

What is needed for setup: server, client, and configs

Minimum stack for a working sharing server: physical smart card of the operator, USB reader (Phoenix, Smargo, internal in the receiver), Linux machine or receiver with OScam/CCcam, open port to the outside. On the client side — receiver with Enigma2 or another Linux firmware and OScam/CCcam in client mode.

Server part: real card and oscam.server

The reader is described in/etc/oscam/oscam.server. Minimum block for Phoenix reader:

[reader]

CAID is the identifier of the conditional access system. Viaccess —0500, Nagravision —1801, Irdeto —0604. Without the correct CAID, OScam will not understand how to process requests.

Client part: oscam.conf, oscam.user, CCcam.cfg

If the client works through CCcam — the config is simple. In/var/keys/CCcam.cfg or/usr/keys/CCcam.cfg on Enigma2:

C: hostname.example.com 12000 username password

One line. C: → host → port → user → pass. Without extra characters.

If the client is on OScam and connects to a CCcam server, inoscam.server add:

[reader]

Users on the OScam server are described inoscam.user. Each client is a separate section[account] with login, password, and restrictions (maximum connections, CAID, packages).

Paths to configuration files in typical builds

Paths vary depending on the firmware and build:

• OScam on Enigma2:/etc/tuxbox/config/oscam/ or/etc/oscam/
• CCcam.cfg on Enigma2:/usr/keys/CCcam.cfg or/var/keys/CCcam.cfg
• OScam on regular Linux:/etc/oscam/, binary in/usr/local/bin/oscam
• OScam logs:/tmp/.oscam/oscam.log (Enigma2) or/var/log/oscam.log

In some OpenPLi builds, the paths are shifted to/etc/tuxbox/. If you can't find the configs — dofind / -name "oscam.conf" 2>/dev/null.

Checking the connection through the log and web interface

The fastest way to check if the connection to the server is working:

tail -f /tmp/.oscam/oscam.log

Look for lines likeCONNECTED orONLINE next to your reader's name. If you seeRECONNECTING in a loop — the server is unavailable or the data is incorrect. This is all visually visible through webif on port 8888: reader table, status, ECM count, time of the last request.

Typical problems and their diagnosis

Most problems can be solved through the log. Not through telepathy, not by rebooting the receiver — through the log. Here’s what to look for.

The channel does not open: ECM unhandled and no card

The lineno matching reader found orECM unhandled in the log means one thing: the server does not have a card with the required CAID or provider-ID. Check what CAID the channel has (through the receiver's menu or through lamedb), and compare it with what the server announces.

Another reason: inoscam.user there is a restriction by services or CAID for your account, and the required channel is not included. Check theservices parameter in the account.

Frequent freezes and CW drops

Freezes occur when the new CW does not arrive within 10 seconds. The reasons, in order of frequency: ping to the server above 150 ms, card overload (too many clients on one slot), unstable internet channel with packet loss.

A special case is a card with a hard ECM limit per second. If the user quickly switches channels and queues the card, other clients freeze. In OScam, this is visible by the parameterecmfailcount in webif.

Another nuance that is often ignored: MTU. On slow or tunneled channels, packets can be fragmented. Keepalive packets from CCcam/OScam are lost, and the connection breaks. Try reducing the MTU on the interface to 1400 and check the behavior.

Time errors (ECM too old) and NTP synchronization

This is one of the most underrated sources of problems. If the receiver has the wrong system time, decryption breaks. The operator embeds a timestamp in the ECM, and if the discrepancy is more than a few seconds, the card rejects the packet with the errorECM too old orECM time mismatch.

Receivers without hardware RTC (real-time clock) lose time after each power outage. After turning on, they start from the year 2000 or a similar date. NTP is mandatory here. Add to autostart:

ntpd -q -p pool.ntp.org

Or configurentpdate in/etc/init.d/ via rc-script. Without this, sharing will work randomly — only until the time drifts apart.

Network issues: NAT, firewall, closed ports

The quickest way to check port availability from the client:

telnet hostname.example.com 12000

If the connection hangs or is immediately refused — the port is closed. Either there is no forwarding on the server's router, or the firewall is blocking it. On the server side, check:

iptables -L -n | grep 12000

Double NAT is a special headache. Some providers issue clients an address from a private range (10.x.x.x or 100.64.x.x), while the external IP is shared across the entire block. In this case, port forwarding on the home router will not help — the request simply won't reach it. Solution: VPN with a public IP or request the provider to allocate a real external address.

Parametersreconnecttimeout andkeepalive in OScam affect how quickly the client detects a disconnection and reconnects. By default,reconnecttimeout = 30 (seconds). If the connection is unstable, reduce it to 10–15.

How to choose an access source: criteria without specific names

It is important to state right away: an official subscription with the operator is the only legal way to watch paid channels. Everything described below concerns the technical criteria for evaluating any access source, if you have already made an informed decision.

Stability and uptime as the main criterion

Claimed uptime of 99.9% is marketing. The real indicator is how many times a month the server went down and how quickly it recovered. Look for forums or chats where users talk about real experiences, not advertising promises.

A monthly test is the minimum. A week’s picture is incomplete: one maintenance or key update by the operator can take the server down for a day.

ECM response time and the number of slots on the card

Ideal ECM time is up to 300 ms. Anything above 700 ms leads to noticeable delays when switching channels. You can check the ECM time through OScam webif after a few minutes of operation.

The number of clients per card is critical. The card physically processes about 4–8 ECM per second, no more. If 50 clients are connected to one card, the queue of requests guarantees freezes for everyone. A normal indicator is no more than 5–10 active clients per card.

Transparency regarding supported CAID and packages

Before connecting, it should be clearly stated which CAID and which provider IDs the server supports. Vague "all popular packages" is a bad sign. A normal source will specify: Viaccess 0500/029600, Nagravision 1801/000000, and so on.

Channels with BISS keys are a separate story — they do not work at all through standard card sharing because BISS does not use smart cards. If a channel is encrypted only with BISS — no sharing will help.

Trial period and technical support

24–48 hours of test access is enough to check the real ECM time, stability, and coverage of channels. If there is no test access at all — this is a reason to be cautious. A normal source is not afraid to show quality.

Technical support should understand what a subscription to satellite TV through sharing is at a technical level: answering questions about CAID, ECM time, OScam config. If support can only send a C-line and say "restart the receiver" — this is not support.