Card sharing: setting up CCcam and OScam in 2026

If you already understand satellite TV and are holding a receiver with Enigma2, then the basic concept of card sharing is likely clear to you. But there is a significant distance between "I understand the basics" and "I set up the server, everything works." This article fills that gap: we will discuss protocols, config syntax, diagnostics through logs—without fluff and without advertising specific services.

What is card sharing and how does it work

Card sharing is a technology for the joint use of a smart card by multiple clients over a network. Physically, the card is in one receiver (or card reader), and its decryption capabilities are provided to remote devices via the internet or local network.

Principle of operation: exchanging ECM/EMM keys

The satellite TV stream is encrypted. Every ~10 seconds, the provider changes the control word (Control Word, CW)—the key used to decrypt the video. To obtain it, the receiver forms an ECM request (Entitlement Control Message) and sends it to the server with the card.

The server forwards the request to the smart card, which returns the CW, and the server sends it back to the client. The receiver receives the word, decrypts the stream—the picture comes through. The entire cycle must fit within those ~10 seconds; otherwise, freezes will occur.

EMM (Entitlement Management Message) is another type of message; it manages the rights of the card itself (activating packages, renewing subscriptions). During sharing, EMM is usually filtered on the server.

The role of the server and client in the scheme

The server is a machine with a physical smart card and an emulator program (CCcam, OScam). It receives ECM from clients, processes it through the card, and distributes the CW back.

The client is a receiver without a card (or with a card without the necessary subscription) that connects to the server over the network. It sends ECM and receives the ready control word. From the receiver's perspective, everything is transparent: it "thinks" that the card is local.

How a local card differs from sharing

With a local card, the decryption delay is milliseconds, as the reader is connected directly. With sharing, this adds network delay, queue on the server, and processing time. A good server provides ECM time of 50–150 ms. A bad one—600+ ms, and then interruptions begin.

Another point: a local card works as long as the receiver is alive. The server can go down, lose connection, or overload. Reliability is higher with a local card, but package coverage is better with a good server with multiple cards.

Encoding systems and access control (CAS)

Satellite providers use different conditional access systems: Viaccess, Irdeto, Conax, Nagravision, Biss, PowerVU. Each system is identified by a CAID (CA System ID)—a four-digit hex code. For example, Viaccess has CAID 0500, Irdeto—0600/1702.

In addition to CAID, there is a Provider ID (provider within the system) and SID (Service ID—a specific channel). These three parameters determine which request a specific reader processes. If they do not match what is specified in the config, the card will not process the request.

Card sharing protocols: CCcam, OScam, Newcamd, MGcamd

Protocols are the language through which the client and server exchange ECM and CW. Different programs support different protocols, and this directly affects compatibility.

CCcam—default protocol and port

CCcam is a proprietary protocol and program developed by a closed team. The default port is 12000, set in CCcam.cfg with the parameterSERVER LISTEN PORT : 12000.

The protocol uses C-line to connect to the server and F-line to distribute the card to its clients. CCcam is still widely used, but development has long been abandoned. The last version is 2.3.x, and there are no new releases.

OScam as a universal solution

OScam (Open Source Cam) is a different story. Open source, active community, support for multiple protocols simultaneously: cccam, newcamd, camd35, radegast, gbox. One daemon can simultaneously accept clients via the CCcam protocol and distribute CW via newcamd.

Configuration is split into several files:oscam.conf,oscam.server,oscam.user,oscam.services. This is more complex than a single CCcam.cfg, but provides flexibility that CCcam lacks.

Newcamd and its role

Newcamd is an old but resilient protocol. The default port is 15000. It operates on a client-server principle and supports DES encryption of the connection. Many cheap receivers only support newcamd, and it is too early to abandon it.

OScam is configured through[newcamd] in the listener section of oscam.conf. The encryption key (DES key) must match on both the server and the client.

Protocol comparison: stability and compatibility

Protocol	Default port	Support in OScam	Status
CCcam	12000	Yes (reader + listener)	Abandoned
Newcamd	15000	Yes	Stable
Camd35	2000	Yes	In use
Radegast	8000	Yes	Rarely

MGcamd is a client emulator (not a server) compatible with newcamd/CCcam. It is often found on older receivers, but on modern Enigma2 boxes, it has been replaced by OScam.

Configuring the OScam server and client

OScam is the main tool for those who want to properly set up card sharing in 2026. We will go through the configs step by step, without omitting details.

Config structure: oscam.conf, oscam.server, oscam.user, oscam.services

oscam.conf — the main config. The section[global] sets basic parameters: logging level, log path, time zone. The section[webif] enables the web interface:

[global]

oscam.server describes readers — sources of cards. Each reader begins with the section[reader].

oscam.user describes the clients to whom the server distributes CW. Each client is a section[account].

oscam.services - filtering by CAID/provider/SID. Here you can limit which channels are available to a specific client.

File location: /etc/tuxbox/config/oscam/ or /var/keys/

The path to the configs depends on the firmware and build. On Enigma2 boxes with OpenATV or OpenPLi, it is usually/etc/tuxbox/config/oscam/. On some builds -/var/keys/. In Gemini and DreamElite, it can be found at/etc/enigma2/oscam/.

You can check where the daemon is running from with the command:ps aux | grep oscam - the output will include the key-c with the path to the config directory.

Setting up the card reader (DVB reader)

The built-in card reader of the receiver is usually available as/dev/sci0 (or sci1 for the second slot). An external USB reader (like SCR3310) is recognized as/dev/ttyUSB0.

Example of a reader for the built-in slot:

[reader]

For the external USB reader, we changeprotocol = mouse anddevice = /dev/ttyUSB0. The parametermhz sets the clock frequency. For most cards, 357 (3.57 MHz) is normal; some cards require 600.

If you need to connect as a client to a CCcam server, the reader looks like this:

[reader]

Setting up client accounts in oscam.user

Each client to whom the server distributes CW is described inoscam.user:

[account]

Parametergroup must match the reader's group — this is how OScam knows which card to use for processing requests from this client.au = 1 enables auto-update (EMM) for the card.

OScam web interface (httpport 8888)

After starting the daemon, open the browser:http://<receiver IP>:8888. The tabReaders shows the status of the card — whether it is active, how many ECMs have been processed, response time. The tabClients — who is connected, how many requests have been processed.

If port 8888 is busy, changehttpport inoscam.conf. HTTPS is also configured there viahttpsport and SSL certificate.

Starting and checking the status of the daemon

Standard start command:oscam -b -c /etc/tuxbox/config/oscam. The flag-b runs the daemon in the background,-c specifies the config directory.

Check if the daemon is running:pidof oscam orps | grep oscam. To stop:kill $(pidof oscam) or via init script/etc/init.d/oscam stop.

Important point: do not run OScam and CCcam simultaneously on one receiver. They will conflict for access to the card reader (/dev/sci0). Choose one.

CCcam setup: configuration file CCcam.cfg

CCcam is still found in old configurations, and knowing its syntax is useful at least for migrating to OScam correctly.

Syntax of C-line, N-line, F-line

C-line — connection to the CCcam server:

C: server.example.com 12000 username password

Format:C: host port login password. You can add parametersno/yes for managing resharing and EMM.

F-line — creating a client account (for incoming connections to your server):

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

Fields after the password: uphops (how many hops the card is passed up), downhops (down), reshare (resharing), and filters by CAID.

N-line — connection via Newcamd protocol:

N: server.example.com 15000 username password 01 02 03 04 05 06 07 08 09 10 11 12 13 14

The long string of numbers at the end is the DES encryption key (14 bytes in hex). It must match the server settings.

Location of CCcam.cfg (/var/etc/ or /usr/keys/)

On DreamBox —/var/etc/CCcam.cfg. On VU+, Formuler, and similar devices — often/usr/keys/CCcam.cfg or/etc/CCcam.cfg. Check where the process is launched from, similar to OScam.

Exchange parameters and hop count

Hop count — the number of intermediate servers through which information about the card is transmitted. The more hops, the higher the latency and lower the stability. For a direct connection to the server with the card — hop 1. If the server, in turn, receives the card from another server — hop 2, and so on.

ParameterSHARE LIMIT : 1 in CCcam.cfg limits the maximum number of hops for sharing. A value of 0 means only local cards, without sharing others.

Local card in CCcam.cfg

CCcam automatically detects the card in the local reader. Managing readers is done through parameters:

SERIAL READER : /dev/ttyUSB0 PHOENIX

For the built-in reader of Dreambox usedINTERNAL SERIAL READERBut honestly, for the local OScam card, it is configured more accurately and behaves more reliably — the migration is justified.

Diagnostics and solving typical problems

Most card sharing issues are resolved by reading logs. Not "restart the receiver," not "try another server" — but specifically log analysis. Let's break down the main scenarios.

Channel does not open: checking ECM

First, we look at the OScam log (/var/log/oscam.log or through the web interface, Log tab). We search for lines with the required SID. If we seenot found (0500&000000/XXXX) — the reader did not find the card for this CAID/provider.

Reasons: incorrect CAID inoscam.server, mismatch between the reader group and the account group, or the channel is not included in theoscam.services list. Regional versions of the same package may have different CAIDs — for example, the same provider may use 0500:042300 and 0500:042800 for different regions. Clarify the CAID through lamedb or in the channel settings on the receiver.

Freezes and long response time (high ping/ECM time)

The normal ECM time is up to 300–400 ms. If the value is consistently above 500 ms — expect freezes. The CW arrives just in time, but with the slightest network delay, the channel breaks up.

What to do: check the ping to the server (it should be up to 100–150 ms for normal operation), check the CPU load of the receiver (in case OScam and some torrent client are running simultaneously), make sure the internet connection is stable — packet losses kill card sharing.

A special case: the provider changed the CW change interval. Usually, this is 10 seconds, but some switch to 5 or even 3 seconds to protect against sharing. If the server cannot process requests at such a pace — freezes are inevitable even with good ping.

Connection error to the server (no C-line)

The log will show something likeconnection refused ornetwork timeout.First, check the C-line manually: is the host, port, login, and password correct? An error in a space or case sensitivity of the password is a common reason.

If the data is correct — check if the port is open on the server. The command from the client side:telnet server.example.com 12000. If the connection cannot be established — the port is closed by a firewall or incorrectly forwarded on the router.

Working behind NAT with a "gray" IP from the provider is a separate problem. If the provider uses CGNAT, standard port forwarding will not work. A VPN with a public IP, reverse tunnel (for example, via SSH), or a service from the provider for allocating a real IP is needed.

Problems with CAID and provider ID

OScam strictly matches requests. If inoscam.server the CAID is specified as0500, but the request comes with CAID0604 — the reader will ignore it. Check the Readers tab in the web interface: it shows how many requests were accepted, rejected, and not found.

Parameterident In the reader section, you can explicitly specify the allowed CAID:ProvID. For example: ident = 0500:042300,042800. Without it, the reader will try all requests in a row, which creates unnecessary load.

Analyzing OScam logs

A typical line of a successful ECM in the log:

 2026/03/15 21:04:22 c (2) client1 [cccam] ECM 0500& 042300/1234/5678 found (55 ms) by internal_card

Decoding: client client1 requested CW for CAID 0500, provider 042300, SID 1234, PMT PID 5678. The request was processed in 55 ms by the reader internal_card. This is a good result.

Line with an error:

 2026/03/15 21:04:22 c (2) client1 [cccam] ECM 0500& 042300/1234/5678 not found (850 ms)

850 ms and not found — the card did not respond in time. Let's check the state of the reader: maybe the card has fallen out of the reader, or the server upstream is not responding.

How to choose a reliable provider: evaluation criteria

If you don't have your own card and want to connect to a paid server — the selection criteria are more important than names. The market is full of intermediaries, and distinguishing a stable service from a random drop is not easy without understanding what to look for.

Uptime and server stability

Declared uptime of 99.9% — this is marketing. Look at how long the service has existed, whether there is a history of incidents. A good sign is when the provider honestly writes about planned maintenance and its duration. No status page and no history? This is already alarming.

The minimum expected uptime for normal operation is 99.5% per month. This is about 3–4 hours of total downtime per month. More than that — it will interfere.

ECM response time

This is the main technical parameter. ECM time below 200 ms — excellent. 200–400 ms — acceptable. Above 500 ms — there will be problems with freezes. If the provider does not specify this indicator — ask for test access and measure it yourself through the OScam web interface.

Support for necessary packages and CAID

Make sure that the server supports your packages. This means: correct CAID, necessary Provider ID, and specific channel SIDs. Ask directly or check through test access — do not trust the list on the main page without verification.

Test period and technical support

A normal provider gives test access for 24–48 hours. Without a test — skip it, regardless of the beautiful description. During the test, you can check the real ECM time, connection stability, and how support works when questions arise.

Technical support should respond substantively, not just send you to read the FAQ. If the answer to the question "what CAID does your server support" is evasive — this is a bad sign.