Card sharing: setting up CCcam and OScam from scratch (2026)

If you are reading this, it means you have already figured out that card sharing is not magic, but a very specific protocol for transmitting decryption keys over the network. The receiver requests the CW from a remote server, which returns the key, and the channel opens. The problem is that most "instructions" on the internet are either outdated screenshots from 2019 or veiled advertisements for a specific provider. Here, it's pure technique.

What is card sharing and how does it work technically

The chain is simple, but each link matters. The receiver receives an encrypted stream from the satellite, extracts the ECM packet (Entitlement Control Message), and sends it to the server. The server passes the ECM through a physical smart card in the reader, which returns the Control Word — an 8-byte key. This CW goes back to the client, which decrypts the stream.

The entire cycle should fit within approximately 300–400 ms. If it doesn't, the picture freezes. The CW changes every 10 seconds, so the server has a small buffer: it can send the next key in advance while the previous one is still working. Hence the requirements for ping: ideally no higher than 80–100 ms to the server.

The principle of transmitting the Control Word (CW) over the network

The CW is transmitted in encrypted form over a TCP connection. The client establishes a persistent connection with the server, authenticates with a username/password pair, and waits for keys. The server either immediately sends the CW from the cache or goes to the card for a new one. If the card is busy, the client waits in line. This is why an overloaded server causes freezes even with excellent ping.

The role of ECM and EMM in the decoding process

ECM is a request for a key for a specific stream. EMM (Entitlement Management Message) is something entirely different: these are service packets that update the rights of the card itself. EMM is not transmitted over the network within the framework of standard card sharing — this is important to understand during debugging. If the card suddenly "loses" channels, it is an EMM problem on the server's physical card side, not the client's.

The difference between the server (card in the reader) and the client

The server is a machine with a real smart card in a USB or internal reader, running CCcam or OScam, and an open port to the outside. The client is a receiver or software player that connects to the server over the network and receives the CW. One server can serve several clients simultaneously, but each physical card processes ECM sequentially, not in parallel. This is the bottleneck in "reselling."

Protocols newcamd, CCcam and their differences

CCcam is both a protocol and a program. The CCcam protocol operates on port 12000 by default, transmits data in encrypted form, and supports the concept of "hops" — the number of transfers between servers. Hop 0 is the local card, hop 1 is a direct connection to the server with the card. Each additional hop adds latency.

Newcamd (protocol, ports usually 15000–15010) is an older protocol used for N-lines. Less flexible in terms of retransmission, but sometimes more stable on weak channels. OScam can work with both. CCcam only supports its own protocol and partially newcamd through emulation.

Setting up the CCcam server and client: step by step

CCcam is still alive on most Enigma2 boxes because it is simple. Version 2.3.x is the last stable one; further development has essentially stopped. For basic client setup, this is more than enough.

Installing CCcam on Enigma2 (path /usr/keys/ and /var/etc/)

On most images — OpenPLi, OpenATV — CCcam is installed via the package manager or by copying the binary to/usr/bin/. Look for the configuration file in/var/etc/CCcam.cfg (OpenPLi, VTi) or/etc/CCcam.cfg (some OpenATV builds). The key files SoftCam.Key are placed in/usr/keys/. If the config file is missing, create it manually; CCcam will pull it in at startup.

On VTi images, the path is different: configs are often located in/etc/cccam/. Before spending hours searching for "why it doesn't work," first check where the daemon actually starts with the commandps aux | grep CCcam and look at the launch arguments.

The structure of the CCcam.cfg file: lines C: and F:

Here is the minimal working client config:

C: server.example.com 12000 myuser mypassword

LineC: — is the connection to the remote server. Format:C: host port login password. You can add parameters after the password:C: server.example.com 12000 user pass 01 02 00 0, where the last values affect priority and filtering, but they are not needed for initial setup.

LineF: — this is a local account for incoming connections (if you are sharing). Format:F: username password 1 0 0. The first number — allow sharing (1) or not (0). The second — hop limit for this user. The third — specific CAIDs separated by commas or 0 for all.

Writing N-line and F-line for sharing

N-line — this is a connection using the newcamd protocol. In CCcam it looks like this:

N: server.example.com 15000 user pass 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08

The long string of hex characters after the password — this is the DES key for encrypting the connection. It is provided by the provider along with the line data. If the key is incorrect — the connection will not be established, and you will see an authentication error in the log.

Restarting the daemon and checking via telnet/web interface

Hard restart:killall -9 CCcam, thenCCcam& or via init script/etc/init.d/softcam restart. The web interface is available on port 16001: open in the browserhttp://<ip-receiver>:16001 — there you can see active connections, card status, and ECM time.

Through telnet on port 16000 you can get a text status:telnet 192.168.1.100 16000. This is useful when there is no browser at hand. Look for lines withCONNECTED — they confirm that the C-line is up.

Configuring OScam: configs and linking with CCcam

OScam — this is another level. It is actively developed, supports many more protocols, has proper logging, and has a decent web interface. For serious work with multiple cards or sources — the choice is obvious. CCcam is easier to set up in 5 minutes, OScam gives more control.

Key files: oscam.conf, oscam.server, oscam.user

OScam configs are located in the directory — on Enigma2 it is most often/etc/tuxbox/config/oscam/ or/var/keys/oscam/. On OpenATV it is often/etc/oscam/. Three main files:

• oscam.conf — global settings, web interface, logging
• oscam.server — description of readers (local cards or remote servers)
• oscam.user — client accounts that connect to OScam

Minimumoscam.conf:

[global]

Configuring reader for cccam protocol (group, caid)

To connect OScam to a CCcam server, inoscam.server add the section:

[reader]

The parametergroup — is a logical group. Inoscam.user clients also specifygroup = 1, which links them to this reader. The parametercaid filters which encryption systems to use this reader for. If not specified — OScam will try everything the client sends, but it's better to limit it explicitly.

The parameterident allows for further narrowing — to a specific provider within the system:ident = 0500:032830. This reduces unnecessary ECM requests and speeds up the response.

Enabling web monitoring on port 8888

After starting OScam, open in your browserhttp://192.168.1.100:8888. You can see everything there: active readers, response time for each ECM, connection status, error counters. If ECM time is consistently above 500 ms — this is already diagnostics, not guessing.

In the "Readers" section, check the "ecm avg" column — this is the average response time. The norm for a working server is 100–350 ms. Above 600 ms with normal ping indicates server overload or a long chain of forwarding.

Linking OScam as a client to a CCcam server

This is perhaps the most common practical task. OScam takes on the role of a smart client: it manages reader priorities, caches CW, and correctly handles timeouts. CCcam acts as the source of keys.

If both are running on one device — watch the ports. CCcam listens on 12000, OScam can raise its own cccam listener on another port. A conflict arises if both try to listen on the same port — check with the commandnetstat -tlnp | grep 12000.

Solution to typical problems: Freeze, interruptions, and errors

“Reboot the receiver” is the worst advice during freezes. It masks the symptom, not treating the cause. Normal diagnostics take 10 minutes and provide a specific answer.

Freeze of the picture and ping check to the server

The first step is ping. From the receiver:ping -c 20 server.example.com. Look not only at the average but also at the maximum value and losses. Packet losses of 2% are already a problem. Ping above 150 ms means potential freezes with each CW change.

The second step is ECM time in the log or web interface. If the ping is 30 ms and the ECM time is 800 ms, the problem is not in the channel but in the server load. Either the server is serving too many clients, or the card is slow, or the hop chain is too long.

A separate case: a receiver with two tuners and a local card for one CAID. If there is also a re-shared card on the same CAID, OScam may choose it instead of the local card. Resolve this through priorities inoscam.server — set the local reader topriority = 1, and the remote topriority = 5.

Error 0500/0100 and CAID mismatch

CAID is the identifier of the encryption system. 0500 — Viaccess, 0100 — Seca/Mediaguard, 1801 — Nagravision, 0604 — Irdeto, 0963 — Videoguard. If the client requests CAID 0500, and the server only provides 1801, there will be no decoding.

In the OScam log, this looks likeCAID: 0500 - no matching reader found orcan't decode. Check the CAID in the request line against what your reader actually supports. In CCcam, this is visible in the web interface on port 16001 in the Cards section.

Message “card not found” and provider issues

“Card not found” in the log is a situation where the CW request reached the server, but there is nothing to respond with. Reasons: the card is not inserted, the card is blocked, the limit of simultaneous connections on the account has been exceeded, or the provider's server is completely unavailable.

First, check your connection: in the CCcam web interface, look at the “Servers” section — the status should be “CONNECTED,” not “REFUSED” or “TIMEOUT.” If the status is normal but CWs are not coming — the problem is on the provider's side.

Another common case: hop limit. If the server is configured to provide a maximum of 1 hop, and you are connecting through an intermediate server — you are already on hop 2, and the keys will not arrive. In CCcam.cfg, the parameterSHARE LIMITS and the settings of a specific C-line determine how many hops are allowed to pass.

Reading OScam logs for diagnosing ECM time

Live log viewing:tail -f /var/log/oscam.log. Look for lines withECM — they show the request, the reader that responded, and the time in milliseconds. Here is an example of a normal line:

2026/04/12 14:23:01 c (user1) ECM 0500/032830/1234 answered by my_cccam_server (234 ms)

If you seenot found (500 ms) — the reader could not respond. Iftimeout — the reader did not respond at all within the allotted time. The parameterecmnotfound in oscam.conf allows you to configure behavior in case of no response.

Working behind NAT adds its own layer of complexity. If you are setting up a server, there is no alternative to port forwarding. Port 12000 (CCcam) or 8080 (OScam cccam-listener) must be accessible from the outside. In the case of double NAT (provider + home router) — you cannot do without a static IP or DDNS. Solve dynamic IP through any DDNS service and use the domain name instead of the IP in the C: lines — it resolves with each reconnection.

How to choose a card sharing provider: criteria (without names)

There are many providers, and the quality varies. I intentionally do not name specific services — this quickly becomes outdated, and today's "best" may be sold and degrade tomorrow. Here is what is really important.

What to look for: uptime, ECM time, and trial period

A decent provider offers a test line for 24–48 hours without payment. Without a test — either they fear inspection, or they sell outright garbage. The declared uptime should be above 99% — and this is not just a number on the website. Ask for statistics or check yourself during the trial period by leaving the receiver on overnight.

ECM time is the main indicator of quality. A good server responds in 100–250 ms. Anything consistently above 400 ms indicates potential freezes on weak channels. Look specifically at the average value over a long period, not a one-time measurement.

Local cards vs reshares and the number of hops

A local card in the server's reader is hop 0 or hop 1 for the client. A reshare is when the server itself is a client of another server. Each additional hop adds 30–100 ms of delay and a point of failure. A chain of three reshares (hop 3–4) is instability by definition.

Ask directly: are the cards local or a reshare? A normal provider will answer honestly. If they evade the question — consider it a reshare.

Support for necessary CAIDs and packages

Before purchasing, clearly define which CAIDs you need. A satellite package on Viaccess (0500) and a package on Nagravision (1801) are different cards. One provider may cover one but not the other. Cross-check the list of supported CAIDs with what your satellite broadcasts.

Signs of an unstable or resold server

Overselling is a scourge of budget providers. Symptoms: ECM time fluctuates from 100 to 2000 ms throughout the day, freezes occur during prime time (evenings and weekends), but everything works perfectly at 3 AM. This is classic overloaded server behavior.

Other signs: technical support takes days to respond, there is no server status monitoring, the price is suspiciously low for the declared quality. If the provider cannot explain how many clients are on one card — that is already an answer.