What is a satellite TV subscription: an analysis for CCcam/OScam

If you are encountering the termsCCcam, OScam, and cardsharing for the first time and want to understand what is happening under the hood — this article is for you. What is a satellite TV subscription on a technical level, how does it differ from the box with the card that your operator provides, and how does softcam fit into this scheme — we will break it down in order, without fluff.

What is a satellite TV subscription and how does it work technically

Essentially, a subscription is the right to decrypt a closed signal. The operator encrypts the video stream on the transponder and provides you with an access card that can decrypt this stream. Without the card, the receiver receives the signal but only sees encrypted garbage.

The chain looks like this: the satellite broadcasts an encrypted stream → the receiver receives it through the transponder → sends the encrypted packets to the conditional access module → the card or softcam returns the control word → the receiver decrypts the video. The entire process takes milliseconds, but any failure at any stage — and you see a freeze or a black screen.

Access card (smartcard) and conditional access module CAS

A smart card is a physical token with the operator's cryptographic keys. It is inserted into the CAM module (Conditional Access Module) of the receiver or directly into the CI/CI+ slot. The conditional access system (CAS) is a set of algorithms and protocols by which the card communicates with the stream: Viaccess, Nagravision, Irdeto, Conax, Cryptoworks — each operator has its own system.

Each CAS is identified by a CAID (Conditional Access Identifier) — a four-byte code. For example, Viaccess 3.x is 0x0500, Nagravision is 0x1800, Irdeto is 0x0600. You will encounter this code in OScam configs constantly, so remember its role: it informs the system which decryption algorithm to apply to a specific channel.

What happens during decryption: ECM, EMM, and control word

The encrypted stream contains two types of service messages. ECM (Entitlement Control Message) is an encrypted packet that contains the control word (CW), which is the key for decrypting the current video. EMM (Entitlement Management Message) is a rights management message that updates the subscription information on the card: activates channels, extends access rights.

The control word changes approximately every 10 seconds (sometimes more frequently — on sports channels, it can be every 2–3 seconds). The card decrypts the ECM and returns the CW to the receiver, which uses it to decode the video. If the CW does not arrive on time — the picture breaks up. That is why response time (ECM time) is so important.

How "subscription" differs from direct access to the transponder

A transponder is simply a carrier frequency from the satellite. Open (FTA, Free-to-Air) channels are transmitted without encryption, and any receiver with the right diameter dish can receive them. Paid channels are transmitted on the same transponder but are encrypted by the operator's CAS. Without the right to decrypt — without a subscription — you have the stream, but you cannot watch it. What a satellite TV subscription is — it is precisely this right, embodied in a card or in a network schemecardsharing.

CCcam and OScam: how softcam replaces a physical card

Softcam is a software implementation of the CAM module. Instead of inserting a physical card into the receiver, you run a program on it (or on a separate server) that intercepts ECM requests and returns the control word. This is OScam or CCcam.

What is cardsharing at the protocol level

Cardsharing is a scheme in which one physical card serves multiple receivers over a network. The server with the card receives ECM from the client, the card decrypts it and returns the CW back to the client. The client sends the CW to its receiver, which then decodes the video. All of this happens over the network — locally or via the internet.

Protocols by which the client and server communicate: CCcam, newcamd, camd35 (also known as cs357x, UDP/TCP), radegast. Each specifies the packet format, authentication, and method of transmitting the CW.

The role of the server and client in the scheme

The server is a machine with a physical card and running OScam or CCcam. It receives ECM from clients, sends them to the card, receives CW, and sends it back. The client is a receiver with softcam configured to connect to the server. The client does not hold the card — it only requests decryption.

An intermediate node is called a proxy or relay: it receives ECM from clients and forwards it to the server with the card. This is useful for scaling but adds latency (hops). In CCcam, the number of intermediate nodes is set by the hop limit parameter — usually no more than 3–4, otherwise the ECM time increases to unacceptable values.

How OScam differs from CCcam architecturally

CCcam is a proprietary solution with closed source code. The protocol by default operates on port 12000. It is easy to set up for a basic scenario, but debugging is limited, and development has long stopped.

OScam is open-source, written in C, supports dozens of protocols and CAS, and is actively forked by the community. It is more flexible in configuration: you can set the priority of readers, fallback, routing by CAID/provider/ident. Logging is detailed — that is why diagnosing problems on OScam is significantly easier. For a serious installation, I would choose OScam without hesitation.

Basic server architecture: ports, protocols, and configuration files

This is where the specifics begin. Remember the ports and protocols — they are needed for configuring the firewall and NAT.

Protocols newcamd, cccam and their ports

The CCcam protocol listens on port 12000 by default. Newcamd (network-camd) is configured manually, most often 15000 or 15050, sometimes the range 15000–15100 for different readers. Camd35 operates over UDP and TCP, the port is set arbitrarily — typically 35000. Radegast is rare, port 8000 by default.

All these ports need to be forwarded on the router (port forwarding) and allowed in iptables/ufw. If the provider has CGNAT (Carrier-Grade NAT) — port forwarding is generally impossible without a VPN tunnel. In this case, WireGuard or OpenVPN is set up, the server listens on the tunnel interface, and the client connects via VPN.

Structure of oscam.server and oscam.user

OScam uses several configuration files. On Enigma2 receivers (Dreambox, VU+, Formuler, and others) they are usually located in/etc/tuxbox/config/oscam/ or/var/keys/. In some builds, the path is different —/usr/keys/. Check viafind / -name oscam.conf 2>/dev/null.

• oscam.conf — global settings: logging level, webif, paths to the log
• oscam.server — description of decryption sources (readers): physical cards, network connections to other servers
• oscam.user — description of clients to whom the server provides decryption: usernames, passwords, allowed CAID
• oscam.srvid — optional mapping of service ID to channel names

In/etc/CCcam.cfg all this is collected in one file: sectionN: for newcamd connections to the server,C: for CCcam clients,F: for sharing with other clients.

Reader, account, and binding by CAID/provider ID

Inoscam.server each reader is described in the section:

[reader]

Parametercaid — which conditional access systems this reader processes.ident — specific provider IDs in the format CAID:ProviderID.group — group for routing.

Inoscam.user the client is described as follows:

[account]

Parametergroup links the client with the reader: a request from client1 (group 1) will be routed to the reader with the same group. If the groups do not match, the client will receive "not found" even with a working card.

The OScam web interface for monitoring runs on port 8888 (parameterhttpport in the section[webif] of theoscam.conf file). Openhttp://192.168.1.x:8888 — see the status of readers, connected clients, and ECM time in real time.

How to choose a subscription source: criteria without reference to names

What satellite TV subscription means in the context of choosing a source is primarily the quality of decryption, which you can measure objectively. Don't trust promises — look at the logs.

Channel stability and server uptime

A good source is one that does not go down at 8:00 PM on Friday when everyone is watching football. The minimum acceptable uptime is 99% per month, which is about 7 hours of total downtime. Check through the OScam log: see how often the reader goes to statusoffline and for how long. Frequent reconnects every 10–30 minutes are a sign of an unstable source.

ECM response time (ms) as a quality indicator

ECM time is a key metric. The norm for comfortable viewing is up to 500–600 ms. 100–200 ms is excellent. Above 800 ms, freezes begin when changing the control word. Above 2000 ms, the channel is practically unusable.

Sports channels with fast ECM (CW change every 2–3 seconds) require special attention: even 400–500 ms is already critical because the next request comes before the previous one has been processed. In the OScam logs, this is visible as a queue of ECM requests and increasing response time.

View ECM time in real time: OScam web interface on port 8888, section "Services" or "Readers". In the log —tail -f /var/log/oscam/oscam.log | grep "ECM".

Support for required CAID and packages

Before connecting to any source, find out which CAID it supports. If you need a package with CAID 0x1800 (Nagravision), and the source only works with 0x0500 (Viaccess) — nothing will work, even with perfect ping and uptime.

Provider ID (ident) is also important: some sources only support part of the packages from one operator. Check through the same OScam log — statusnot found with the correct CAID usually means a mismatch of provider ID in the reader settings.

Typical problems and their diagnosis

Most problems are solved by reading the log. It sounds trivial, but 90% of questions on forums are resolved this way.

The channel does not open: reading the OScam log

First of all —tail -f /var/log/oscam/oscam.log. Look for lines with the channel name or CAID. Possible statuses of the ECM request:

• found (500 ms) — decryption was successful, CW delivered
• not found — no reader was able to decrypt. Reason: unsupported CAID/ident, incorrect groups, card not activated for this package
• timeout — the reader did not respond in the allotted time. Reason: network, overloaded server, too high ECM time
• rejected — authorization failed. Check the login/password inoscam.user and on the client

If you seenot found — first check CAID and ident inoscam.server against the real CAID of the channel. You can find the channel's CAID in the receiver's signal information or through a specialized plugin (for example, DreamInfoExtractor on Enigma2).

Freeze and picture breakup

Freeze during regular picture changes — almost always high ECM time or an unstable network between the client and the server. Diagnostic algorithm:

1. Check ECM time in the OScam web interface — if it jumps above 800 ms, the problem is in the source or network
2. Ping the server:ping -c 100 IP_server — check for packet loss and jitter. Even 1% loss can cause freeze
3. Check the load on the reader: if too many clients are connected to one server, ECM time increases proportionally
4. If the problem is only on sports channels — likely fast ECM. Try the parameterecmwhitelist inoscam.server or reducereconnecttimeout

Sometimes the cause of freeze is a time mismatch on the receiver. EMM messages contain timestamps, and if the receiver's clock is off from the server by more than a few minutes — EMM is rejected, rights are not updated, the channel is closed. Check viadate in the receiver's console and synchronize via NTP.

Connection errors reader/account

If the reader does not connect, check:

• netstat -tulpn | grep 12000 — whether OScam is listening on the required port
• Port forwarding on the router — many forget about this when moving to a new router
• Firewall:iptables -L -n | grep 12000 orufw status
• Exact match of the login and password inoscam.user on the server and in the client settings. Case matters
• Parametergroup — the client and reader must be in the same group

If you have multiple sources — a local card and a network server simultaneously — OScam accesses them in order of priority. The parameterpriority inoscam.server sets the order: a lower value = higher priority. The local card is usually set to priority 1, the network source to 2 — then the network is used only as a fallback.

A special case is double encryption. Some channels use BISS encryption on top of the main CAS operator. The standard cardsharing scheme will not help in this case: the BISS key is static and set separately, not through cardsharing. OScam supports BISS through the fileoscam.srvid and the static key configuration in the reader, but that is a separate topic.