Cardsharing: what it is, how CCcam and OScam work

Cardsharing is a technology for sharing a pay-TV smart card over a network. One receiver with a real card is connected to the server, while other clients receive encrypted keys for decoding the stream from it. It sounds simple, but under the hood, there is a chain of ECM/EMM requests, Control Words, and precise timing. If there is a delay somewhere, the picture freezes. Let's break down how this works technically.

What is cardsharing and how does it work technically

The satellite signal is transmitted in encrypted form — a scrambled stream. To decrypt it, the receiver needs a Control Word (CW) — an 8-byte key that changes every 7–10 seconds. The CW itself is encrypted in an ECM (Entitlement Control Message), and only an authorized smart card with rights to this package of channels can decrypt it.

In cardsharing, the client receiver sends an ECM to a remote server, where the smart card decrypts the key and returns the CW to the client. The client decodes the stream. All of this happens within 100–400ms — imperceptibly to the viewer. The traffic is minimal: about 1–2 KB/s per channel.

The principle of ECM/EMM exchange between the server and the client

ECM (Entitlement Control Message) is a request for obtaining a CW for a specific channel. EMM (Entitlement Management Message) are messages for updating card rights and managing subscriptions. Under normal operation, EMMs go directly from the provider to the card through the reader, while ECMs go from clients to the server and back.

Every time the receiver switches channels or the current CW expires, it sends a new ECM request. The server receives the request, forwards the ECM to the physical card, the card returns the CW, and the server sends it to the client. The entire cycle must be completed before the next CW change — otherwise, there will be a freeze.

The role of the smart card, CAM module, and DVB receiver

The smart card is a physical token with a chip that stores keys and subscription rights. The CAM module (Conditional Access Module) is the interface between the card and the receiver, inserted into the Common Interface slot. The DVB receiver is the hardware component that receives the satellite signal and sends the ECM for processing.

In cardsharing, the CAM and card are located on the server side. The client receiver operates in softcam mode — a software emulator that intercepts ECM and sends it over the network instead of using the local CAM.

The difference between a local card and remote sharing

With a local card, the entire process occurs within a single device — the ECM goes to the CAM, and the CW is returned immediately. The delay is about 20–50ms. In remote sharing, network latency, server load, and possible packet loss are added. Therefore, an ECM time of 100–400ms is considered normal, while above 800ms is already a problem.

Protocols CCcam and OScam: key differences

The two main standards in the world of cardsharing areCCcam and OScam. They solve the same problem but in different ways. Understanding the difference is important if you are setting up a server from scratch or choosing what to install on the receiver.

CCcam: proprietary protocol, ease of setup

CCcam was developed by the Dream Multimedia team and was for a long time the de facto standard for Dreambox. The protocol is proprietary, and binaries were distributed for specific platforms (mips, arm, x86). Development stopped around version 2.3.x — there are no new releases.

Pros: simple configuration through a single CCcam.cfg file, understandable logic of F-line/C-line/N-line. Cons: closed code, no support for new types of readers, consumes more CPU under high load (50+ clients) than OScam. Nevertheless, the CCcam protocol remains the standard for inter-server exchange — most networks use C-line specifically for this purpose.

OScam: open-source, flexibility, support for newcamd/cccam/camd35

OScam is an open-source project that is actively developed. The latest builds are available in the official SVN repository. It supports readers: PCSC, smartreader+, internal (built-in Dreambox slot), phoenix, mouse. Client protocols: newcamd, cccam, camd35, gbox, radegast.

For the server side, OScam is significantly more flexible: you can set user limits, cache-exchange between servers, and prioritize CAID. CPU consumption is lower under the same load. The WebIF on port 8888 provides full visibility of what is happening — active clients, ECM time, card status in real-time.

When to use MGcamd, Gbox, NewCS

MGcamd is a lightweight softcam that works well on older receivers with limited CPU (Dreambox 500S, TM-5402). It consumes less memory than OScam. Gbox is a protocol for peer-to-peer card sharing between servers, used in large networks. NewCS is anothercard server, simpler than OScam but significantly less flexible.

On modern receivers (Zgemma, VU+, Edision) with OpenATV or OpenPLi — OScam via dvbapi. On older devices with 64MB RAM — MGcamd. For pure peer-to-peer without clients — Gbox.

Setting up a CCcam server on Linux (Debian/Ubuntu)

For the server, you need Linux x86_64, at least Debian 10 or Ubuntu 20.04. The CCcam binary needs to be downloaded in the required version for the architecture. For ARM servers (RPi, Odroid) — ARM binary. MIPS — only for routers with OpenWRT, not recommended for production.

Installing the binary and the structure of /var/etc/CCcam.cfg

# Copy the binary

The log is written to/tmp/CCcam.log by default. For production, it is better to override:LOGFILE = /var/log/CCcam.log.

Configuration of F-line, C-line, N-line, R-line

File structure/var/etc/CCcam.cfg:

# F-line — add user (server accepts connections)

Reshare parameter in F-line: 0 = no resharing, 1 = resharing without restrictions. AU (auto-update) — transmission of EMM to the client for updating card rights, usually 0 for clients.

Opening port 12000/TCP and forwarding through iptables

# Open port in iptables> /etc/iptables/rules.v4

If the server is behind NAT — port forwarding 12000/TCP on the router is needed. Clients connect to the external IP. For dynamic IP — DDNS is mandatory (duckdns.org, no-ip.com): otherwise, when the IP changes, all C-lines for clients will stop working.

Running as a systemd service and auto-start

# /etc/systemd/system/cccam.service

systemctl daemon-reload

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

OScam stores configs in several files, each responsible for its part. The main directory on most systems:/etc/tuxbox/config/oscam/ or/etc/oscam/. The first path is more common in Enigma2 distributions.

Structure of /etc/tuxbox/config/oscam/

/etc/tuxbox/config/oscam/

Minimal workingoscam.conf:

[global]

Reader sections for PCSC, internal, smartreader+

Exampleoscam.server for USB reader (Smartreader+ or phoenix):

[reader]

For built-in slot Dreambox (internal reader):

[reader]

For PCSC (computer with USB reader type Omnikey, ACR38):

[reader]

WebIF on port 8888 and dvbapi for Enigma2

WebIF is available athttp://ip-server:8888. It shows: list of active clients, ECM time for each request, status of the reader, queue of requests. If ECM time is consistently above 600ms — the problem is either with the load on the card or in the network.

Section[dvbapi] needed for direct operation with Enigma2 — OScam connects to the receiver's demux and provides CW directly, bypassing the CCcam protocol. This is more stable and faster. For Dreambox and VU+ — standard solution.

Cache-exchange and peer-to-peer exchange

OScam supports cache-exchange (CSP — CacheEX, Peer-to-Peer) — servers exchange already decrypted CW, reducing the load on physical cards. Configured inoscam.conf:

[cacheex]

And inoscam.server for peer server:

[reader]

Client connection: receiver, OpenATV, Dreambox

On the client side, the setup is simpler — you only need to write the C-line and ensure that the server is accessible. But small details — hostname, port, file permissions — often become sources of problems.

Installing CCcam plugin via feed or ipk

On OpenATV/OpenPLi, CCcam is installed via Package Manager or manually:

# Via opkg

After installation, the binary appears in/usr/bin/CCcam, config —/etc/CCcam.cfg.

Editing /etc/CCcam.cfg on the client (C-line)

# C-line — connection to the server

Important: hostname must resolve from the receiver. Check:nslookup myserver.duckdns.org. If the provider issues a dynamic IP — set up a DDNS client on the server (ddclient, inadyn). With CGNAT (carrier-grade NAT) — direct connection is impossible, a VPS relay with proxying through stunnel or SSH tunnel is needed.

Check via telnet and WebIF on port 16001

# Telnet to CCcam Info

CCcam WebIF (if enabled in the config viaPORT = 16001) shows the list of connected servers, cards, and their CAID. If the card list is empty — the server is not transmitting cards: incorrect C-line, wrong password, or the server has blocked the connection.

Restarting enigma2 and init.d scripts

# Restarting softcam

Troubleshooting: freeze, FTA only, channel not found

Most problems boil down to three scenarios: the card does not provide the required CAID, ECM time is too high, or the receiver does not see the softcam at all. Let's analyze each case by logs.

Diagnostics via log: rejected, no card found, timeout

Typical entries in/tmp/CCcam.log:

# No card with the required CAID

"no card found" — the server does not have a card with the required CAID. Either the provider does not support this package, or the card is not authorized for the channel. "ECM rejected" — the user is connected, but does not have rights for resharing or for this CAID.

Problems with ECM time>800ms and reasons

If ECM time is consistently above 800ms, the picture will freeze every 7–10 seconds. Reasons in descending order of frequency:

• High ping between client and server (>200ms) — choose a geographically closer server
• Reader overloaded on the server — too many clients on one card (norm ~5–8 simultaneous streams)
• Packet loss in the network — checkping -c 100 server-ip, look at packet loss
• Slow reader — Phoenix and clone readers are sometimes slower than Smartreader+ under heavy loads

With high ping, cache-exchange helps — OScam can get already decrypted CW from a neighboring server faster than waiting for the card.

CAID, provider ID, SID conflicts

Some channels are available through multiple CAIDs (for example, the same channel can come through 0500 and 0604). If the receiver tries to decrypt through the wrong CAID, the request will go to the server without the needed card.

In OScam, you can set CAID priority throughoscam.conf: section[camd35] or through the servicepreferlocalcards = 1. In CCcam — through R-line specifying CAID. Provider ID and SID conflicts are most often visible in the log as "wrong provider" or "SID not in service list".

Two softcams simultaneously (CCcam + OScam) on one receiver — guaranteed conflict. Both try to capture/dev/dvb and dvbapi. Always leave only one active softcam.

Network problems: NAT, firewall, MTU

CGNAT — a common problem with mobile and some cable providers. The external IP belongs to the provider, direct incoming connection is impossible. Solution: VPS with a public IP, on which stunnel or SSH tunnel is launched, the client connects through it.

MTU by default is 1500, but some providers cut it down to 1452 (PPPoE) or 1400 (VPN). If packets are fragmented, ECM time will increase. Check:ping -M do -s 1472 server-ip. If there is no response, the MTU needs to be lowered on the interface.

Corporate firewalls often block ports 12000, 10000–15000. Solution — move CCcam to port 443 or 80 throughPORT = in CCcam.cfg. Legitimate HTTPS traffic is usually allowed.

How to choose a cardsharing provider: criteria without advertising

The market of cardsharing providers is opaque. Many services take payment and disappear. Let's break down technical and organizational criteria — what really affects quality.

Technical indicators: ECM time, uptime, server location

A good provider declares SLA with uptime ≥99% and average ECM time<500ms. But declarations are one thing, reality is another. Request a trial period (at least 24 hours) and check ECM time in WebIF OScam or in the CCcam log at different times of the day: during prime time, the load on the cards is maximum.

For Europe, the optimal server location is Germany or the Netherlands. Ping from most European countries is 20–50ms. Servers in Asia or the USA will give a ping of 150–300ms — ECM time will be on the edge.

Support for necessary packages and CAID

The provider must explicitly state the list of supported CAIDs and packages. Sky Germany — CAID 0x09C4 (NDS/Videoguard), Canal+ — 0x0500 (Viaccess), Sky UK — 0x0963. If the provider says "all channels of the world" without specifics — this is a red flag.

Clarify support for a specific package before payment. V14 and V15 Sky cards require specific reader settings — not all providers support them correctly.

Connection conditions: number of connections, freeze policy

Standard — 1 connection = 1 simultaneous stream. Some providers offer multi-connection (2–5 streams per account). Clarify the freeze policy: a normal provider compensates for downtime or provides credit. "No guarantees" in the terms is already a signal.

Also ask about the reconnect policy — how many times per day you can reconnect. Some providers ban accounts for too frequent reconnections (this is an indicator of account sharing among users).

Trial period and technical support

A provider without trial access is either unsure of quality or operates on a "took the money and disappeared" scheme. The norm is from 24 to 48 hours of trial period. During this time, you can check ECM time, stability, and the functionality of necessary packages.

Technical support should respond within a few hours, not days. Check this before payment — ask a question in the chat. If the response is after 12 hours or through a bot — it will be the same with a real problem.

Signs of scammers: payment only for a year without a test, promises of "all packages in the world" without details, lack of real technical support, contact only through anonymous messengers.