Cardsharing IPTV: setting up CCcam and OScam from scratch

If you have already figured out the basics of satellite or cable reception and now want to understand how cardsharing IPTV works in conjunction with emulators — this article is for you. No theory for the sake of theory: only configs, file paths, real commands, and a diagnostic algorithm when something goes wrong.

What is cardsharing and how is it related to IPTV

Two different things that are often confused. Cardsharing is a technology for distributing decryption keys over a network. IPTV is a method of delivering the video stream itself. One works without the other, but together they provide interesting combinations.

How it works: control word and key exchange

An encrypted DVB stream or IPTV stream does not carry keys in plain text. Every few seconds (usually 10–20 seconds), ECM packets — Entitlement Control Message — appear in the stream. Inside are encrypted control words (DCW), two 8-byte keys (odd and even). Without their decryption, there is no picture.

A smart card with an active subscription can decrypt ECM and return DCW. Cardsharing takes this DCW and transmits it over the network to other clients. The client connects to the server, sends ECM, receives DCW in response — and applies it locally to decrypt the stream.

EMM (Entitlement Management Message) — a separate type of packets that update rights on the card. For basic setup, EMM is less important, but OScam can forward them, which helps with auto-renewal of subscriptions.

The difference between classic cardsharing and IPTV delivery

In classic satellite reception, the tuner itself receives the stream from the transponder. The cardsharing client receives the key and decrypts the stream locally on their equipment. IPTV, on the other hand, delivers a ready-made video stream (often already decrypted on the provider's side) over an IP channel.

In the cardsharing IPTV scheme, everything is a bit more complicated: the stream can come through a DVB tuner or via an IP stream in MPEG-TS or HLS format, and decryption keys are requested from a remote cardsharing server. This is used, for example, in DVB-over-IP solutions or on Enigma2 set-top boxes with an external streamer.

Where the line of legal use is drawn

The entire material of this article is of a technical and informational nature. Cardsharing is legal only in conjunction with legally acquired smart cards and an active subscription to packages. Using someone else's cards without the rights holder's permission is a violation of the law in most countries. The described protocols and configs are also used in legal scenarios: home multiroom, laboratory tests, plugin development.

Protocols and ports: CCcam, newcamd, MGcamd, OScam

There are several protocols for key exchange, each with its own specifics. The choice affects latency, stability, and compatibility with your equipment.

CCcam protocol and default port

CCcam operates over TCP. The default port is 12000, set by the directiveSERVER LISTEN PORT in the config. The client connection string looks like this:

C: host port username password

The protocol is proprietary and binary. The CCcam daemon on the server accepts connections, checks credentials, and begins responding to ECM requests. The overhead is minimal, but the protocol is closed — extensibility is limited.

newcamd: connection string format and ports

newcamd typically operates on ports 10000–15000. The connection string in the client config:

N: host port username password DES-key

DES-key — 14 bytes in hexadecimal format, for example01 02 03 04 05 06 07 08 09 10 11 12 13 14. It must be specified identically on the server and client. The protocol is somewhat outdated, but is still supported by most emulators and many hardware receivers.

OScam as a universal protocol gateway

OScam is not just another emulator. It simultaneously understands cccam, newcamd, camd35, radegast, and cs378x, can accept connections via one protocol and forward requests via another. For example, a CCcam client connects to OScam, which then forwards ECM to the physical card or remote server via newcamd.

This makes OScam an ideal hub in mixed schemes. The configuration is more detailed — but the control is complete.

Comparison of latency and stability of protocols

CCcam in a simple "one server — one client" setup gives good results. But in chains of several hops, each node adds latency. newcamd is slightly faster on short routes due to less handshake. camd35 (cs378x) shows minimal latency when directly connected to the card, but is less compatible with "budget" hardware.

For cardsharing IPTV with frequent control word changes (every 10 seconds), it is critical that ECM time does not exceed 500–600 ms. Otherwise, you will experience freezes.

Setting up OScam: configuration files step by step

OScam stores configs in a separate directory. Standard paths:/etc/tuxbox/config/oscam/ (Enigma2 boxes) or/var/etc/oscam/ (some distributions). The binary is usually in/usr/bin/oscam. Start with an explicit path to the configs:

oscam -b -c /var/etc/oscam/

Flag-b — background mode. Without it, OScam runs in the foreground, which is convenient for initial debugging.

oscam.conf: global parameters and web interface

The main config is —oscam.conf. Minimal working version:

[global]

The web interface athttp://192.168.1.x:8888 — your main monitoring tool. It shows the status of readers, active sessions, and the ECM response time in real time. The parameterhttprefresh sets the auto-refresh of the page in seconds.

oscam.server: description of readers and connections

Each reader is a separate block inoscam.server. Example for a CCcam source:

[reader]

For a newcamd connection, replace the protocol and addkey:

[reader]

The parametergroup is critically important. Readers and accounts are linked through group numbers. If the groups do not match, the client will not receive responses from the reader, and you will be scratching your head for a long time wondering why the reader is online but the channels are not opening.

oscam.user: accounts and groups

The fileoscam.user describes the clients that connect to OScam:

[account]

The parameterau = 1 enables auto-update of rights (EMM). The fieldexpdate sets the expiration date of access in the format YYYY-MM-DD — convenient for managing test accounts.

oscam.services and binding by CAID/provid

Fileoscam.services allows limiting access to specific packages by CAID and provider ID. Example:

[VIASAT]

Inoscam.user you can bind the account to the service:services = VIASAT. Inoscam.server — limit the reader with the necessary CAID viacaid = 0500. This is important if you have multiple sources with different packages: without routing by CAID, OScam will poll all readers in sequence, increasing latency.

Starting, logs, and checking via webif

After starting, check the log:

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

In the web interface, the sectionReaders will show the status of each reader: Connected, Disconnected, or Not configured. The sectionEMM andECM displays requests and response times in real-time. Normal ECM time is up to 300–400 ms. 600+ is already a problem.

Configuring CCcam.cfg on the client and server

The default CCcam config is located at/var/etc/CCcam.cfg. The syntax is simple, but several key points are often overlooked.

Lines C: for the client and F: for sharing

Client connection line to the server:

C: server.example.com 12000 myusername mypassword

Sharing line — for sharing cards with your clients (server side):

F: clientuser clientpassword 1 0 0 { 0:0:1 }

Format of the F-line: login, password, uphops, downhops, au (0 or 1), and optional CAID filter. Do not open F-lines without filters and limits — anyone who knows the login/password will gain access to everything your server has.

Parameters hops and SHARE LIMITS

Hop is a "jump" between the card and the end client. Hop 1 means that the client is directly connected to the server with the card. Each intermediate server adds a hop and latency.

In the global section of CCcam.cfg:

SHARE LIMITS : 10

SHARE LIMITS limits the number of simultaneous clients.MINIMIZE DELAY includes optimization of the ECM request queue — with cardsharing iptv this significantly reduces latency.

Files CCcam.cfg, CCcam.prio and CCcam.channelinfo

CCcam.prio — prioritization of sources when there are multiple readers with the same CAID. Format:

P: CAID:provid:srvid = CAID:provid:srvid

For example, if a channel is available from two providers (two different provid under one CAID), through CCcam.prio you can explicitly specify which source to take the key from first. Without this, CCcam chooses itself — not always successfully, hence the periodic freezes on multi-package channels.

CCcam.channelinfo contains a list of channels with names and SID — convenient for readable logs, does not affect stability.

Combining CCcam and OScam on one device

You can run both daemons simultaneously on one device, but they must not listen on the same port. The standard scheme: OScam accepts CCcam clients on port 12000, and itself acts as a client to an external server. CCcam either does not start or listens on another port (for example, 12001).

Inoscam.conf add a section for the CCcam server:

[cccam]

Now CCcam clients (receivers, plugins) connect to OScam as to a regular CCcam server, and OScam itself decides which reader to forward the request to. This is a powerful scheme for multi-protocol environments.

Diagnosing freezes and typical errors

Most problems are solved by reading logs. But you need to know what exactly to look for there.

Channel does not open: reading ECM logs

In the OScam log, each ECM request looks something like this:

2026/01/15 14:23:01 c (clientname) ECM [CAID:0500/PROVID:032830/SID:1234] found (310 ms) by my_cccam_server

Statusfound — key received, all ok.not found — no reader was able to respond.timeout — reader did not respond in time (threshold is set viactimeout in oscam.conf, usually 3000 ms).

If you seenot found with a live reader — it is almost always a CAID/provid mismatch or the absence of the required package at the source.

Freezes and long response time control word

ECM time above 600–800 ms causes freezes with frequent changes of the control word. On some channels, the change occurs every 10 seconds, on others — every 30 seconds. The former give noticeable artifacts already at 500 ms delay.

Check the ECM History section in the OScam web interface — it shows the response time for each channel. If one specific reader consistently gives 700+ ms — the problem is with it (high ping, server overload, long hop chain). Try another reader or switch to a reader with fewer hops.

CAID/provid mismatch errors

Reader online, ECM requests are sent, butnot found arrives. A classic scenario: inoscam.serverthe specified provid is incorrect or not specified at all, and the server only provides a specific package. The solution is to explicitly specify CAID and provid in the reader block:

caid = 0500

The second option: the card is available at the source, but the subscription for the requested package has expired. Then the readerconnected, CAID matches, but ECM returnsnot foundat the card level itself. This is not your configuration error — it is a source problem.

Network issues: NAT, firewall, port forwarding

Checking port availability is elementary:

telnet server.example.com 12000

If the connection cannot be established — firewall or incorrect address. If the server is behind NAT without a public IP, clients outside will not be able to reach it without port forwarding on the router or without a reverse tunnel (for example, through autossh).

A separate issue — the provider blocks non-standard ports. In this case, change the CCcam port (for example to 443 or 80), although this is a workaround. More reliably — a VPN tunnel between the client and the server.

And one more point that almost no one mentions: desynchronization of system time on the receiver. If your device drifts more than 30–60 seconds, some implementations of the protocol start rejecting ECM responses as outdated. Set up NTP:

ntpdate -u pool.ntp.org

And add it to cron or autostart. This really breaks decryption with a formally working connection.

How to choose a server: criteria without tying to names

I will not name specific providers — not because I am hiding, but because the market changes quickly, and yesterday's reliable service may disappear tomorrow. It’s better to learn to evaluate any server independently.

Stability indicators: uptime and ECM time

Declared uptime of 99.9% means nothing without verification. The real test is to connect in test mode and watch the logs for at least several hours, preferably during prime time (Friday evening — Saturday).

What to look for in the logs: average ECM time (should be consistently below 400 ms), the number oftimeoutevents (acceptable — single digits per hour, tens — bad), number of hops (visible in the CCcam log or in the OScam web interface). Hop 1–2 — good, hop 3+ — high risk of instability.

Support for required CAID and packages

Clarify before connecting which specific CAID and provider ID are supported. Common CAID: Nagravision — 1801, Viaccess — 0500, Irdeto — 0604/0606, Conax — 0B00, Cryptoworks — 0D00. The same CAID can be used by different operators with different provid — clarify both values.

A good sign is the presence of a local card at the source (hop 0 or 1), rather than reselling someone else's share with 3–4 hops. This directly affects ECM time in cardsharing IPTV scenarios with frequent key changes.

Trial period and transparency of conditions

Normal practice is trial access for 24–48 hours before payment. During this time, you will have time to conduct a full test in your conditions: with your equipment, your internet channel, your channels.

If they do not provide a test or only give it for an hour at night — this is a red flag. Also, look at the adequacy of support: ask a technical question before payment. The response will show who you are dealing with.