Cardsharing server: setting up CCcam and OScam 2026

If you are reading this, you probably already know what a cardsharing server is in general terms and want to figure out how to set it up correctly and make it work without freezes and black screens. There is no fluff here — only configs, commands, and real paths to files.

What is a cardsharing server and how does it work

The essence is simple: you have a physical smart card with an active subscription inserted into a card reader or CI module. The satellite receiver receives an encrypted stream (ECM — Entitlement Control Message), sends it to the server, which decrypts it through the physical card and returns the control word — an 8-byte key that decodes the video. All this happens in milliseconds, and if everything is set up correctly — you don’t think about it.

An important point: this is about setting up software to work with your own legal cards and test setups. Using someone else's subscriptions without the operator's permission is a different story, with its own legal risks, which I will discuss separately.

The principle of key exchange (control words)

ECM comes along with the encrypted video stream. The server receives the ECM, sends it to the card reader, the card returns the CW, and the server transmits the CW to the client. The entire cycle normally takes 100–300 ms. If it exceeds 400 ms — expect a freeze.

EMM (Entitlement Management Message) — a separate story. These are messages for updating rights on the card. They need to be passed through the reader; otherwise, the card will "die" sooner or later after the rights expire. In OScam, this is handled by the parameterau=1.

The role of the server and client in the sharing scheme

The server is a machine with a card and a daemon (CCcam or OScam) that listens for incoming connections. The client is a receiver or another computer that connects to the server to obtain the CW. One server can serve multiple clients simultaneously, but the load on the uplink increases linearly.

There are different topologies: one server with a card and several clients, or a cascading scheme where the server itself is a client of another server higher up the chain. In a cascade, each "jump" adds latency.

How CCcam, newcamd, and MGcamd protocols differ

CCcam — a protocol with the same name software. Binary, proprietary (reverse-engineered at one time), well supported by receivers based on Enigma2. It operates on TCP, with a default port of 12000.

Newcamd (newcs) — an old protocol that works through DES encryption. The port is usually 15050 or set manually. It is supported almost everywhere, including old receivers.

MGcamd — client software that uses the newcamd protocol. As a protocol in its pure form, it is encountered less frequently; more often, it is specifically the client. OScam can emulate all three options simultaneously — this is its main advantage.

Setting up the server on CCcam: config files and ports

CCcam is what most people start with. There is one config, the syntax is straightforward, and the web interface works out of the box. The downside is that the project is essentially abandoned, with the last active versions being 2.3.x.

Structure of /var/etc/CCcam.cfg

The main config is located in/var/etc/CCcam.cfg on Enigma2 boxes. On Linux systems, the path may be/etc/CCcam.cfg. The keys for decoding (SoftCam.Key) are in/usr/keys/SoftCam.Key.

The basic structure of the file looks like this:

Parameters of F-line, C-line, and N-line

C-line — connection to a remote CCcam server as a client. Syntax:C: host port login password. You can add multiple C-lines for redundancy — CCcam will try them in order.

F-line — creating a client account to which you grant access. Syntax:F: login password hop-count allow-sharing allow-remote { caid:ident }. The first parameter after the passwords is hop count (usually 1). In curly braces is the list of CAID to which access is allowed. Empty braces mean "all."

N-line — connection via the newcamd protocol. Syntax:N: host port login password DES-key. DES-key is 14 bytes in hex, usually looks like0102030405060708091011121314.

Opening port 12000 and forwarding through NAT

This is where 80% of users run into issues. If your server is behind a router without a public IP — clients outside cannot reach it without port forwarding.

On the router, you need to create a rule: external TCP 12000 → internal server IP, port 12000. The same for port 16001 if you want access to the web status from outside (better not to — close it with a firewall).

If there is no public IP at all — the solution is through VPN (WireGuard or OpenVPN) with a server on VPS. Clients connect to the VPS, and the traffic is tunneled to your server. An alternative is dynamic DNS (DynDNS, No-IP) if the provider gives at least a dynamic public IP.

Check:telnet your-server-ip 12000 — should establish a connection. If it refuses — check the firewall (iptables -L -n) and the status of the daemon.

Starting the daemon and checking the status

On Enigma2: via the plugin menu or with the commandinit.d/CCcam start. On a clean Debian/Ubuntu:

&

The web interface opens athttp://your-ip:16001. There you can see the connected client lines, their status, response time, and active CAID. If the line is green — everything is fine.

Configuring the server on OScam: dvbapi and oscam.server

OScam is another level. Actively supported, can work simultaneously with several protocols, provides detailed logs and fine-tuning of each reader. More complex to configure, but ultimately more stable and transparent.

Configs are usually located in/etc/tuxbox/config/oscam/ on Enigma2 or in/var/keys/oscam/. On Debian systems —/etc/oscam/. Three main files:oscam.conf,oscam.server,oscam.user.

Files oscam.conf, oscam.server, oscam.user

oscam.conf — global settings and module activation. Example section[global] and[webif]:

oscam.user — client accounts. Section[account] for each client:

Configuration of the newcamd and cccam protocols in [cccam]

To allow OScam to accept connections from CCcam clients, a section inoscam.conf:

For newcamd clients — section[newcamd]:

Here0500 — provider CAID,000000 — ident. After@ is the port binding to a specific CAID — this is important when working with multiple operators.

Reader binding and caid/ident parameter

Fileoscam.server describes physical and virtual readers. Example of a reader for a local card via phoenix interface:

Example of a reader for connecting to a remote CCcam server:

Parametergroup must match the group inoscam.user — otherwise the client will not gain access to the reader. This is a typical mistake during the initial setup.

The web interface webif on port 8888

Opens athttp://your-ip:8888. It shows everything: the status of each reader, connected clients, real-time ECM decoding time, and the table of active CAIDs. This is the main diagnostic tool.

If webif does not open — check that port 8888 is not occupied (netstat -tlnp | grep 8888) and that inoscam.conf the section[webif] is enabled. Sometimes adding the server's IP tohttpallowed helps.

Diagnosing problems: black screen and freezes

A black screen after switching channels is the most common complaint. There are several reasons, and they are not always obvious. The diagnostic algorithm: check the logs, check the ECM time, check the status of the readers in webif.

Analyzing ECM/EMM logs and response times

The OScam log is by default written to/tmp/.oscam/oscam.log. To view in real time:

A normal line looks something like this:

&000000/1234/...) ECM answer: 287 ms

A time of 287 ms is excellent. Up to 400 ms is acceptable. More than 400 ms — expect a freeze, especially on HD channels. At 600+ ms, decoding starts to lag behind the stream.

In CCcam, there is no detailed ECM log — this is one of the arguments in favor of OScam for serious diagnostics.

Errors 'card not found' and rejected

card not found in the log means: OScam received an ECM request with a specific CAID but did not find any suitable reader. Most often, the reason is a mismatch of CAID or ident in the section[reader].

Check this way: in webif, see what CAID comes in the request, and compare it with what is specified in the reader. Sometimes the operator uses several idents for different transponders — you need to add all of them separated by commas.

rejected — is different. This means that the reader was found but rejected the request. Possible reasons: the card does not have rights to this package of channels, the card was not read at startup, a physical problem with the card reader.

High ping and image freeze

If the server is geographically far away — a ping of 80–120 ms is already a problem. Add to this the processing time on the server (50–150 ms) and the response return time — it easily exceeds 400 ms.

HD channels are especially sensitive: there, CW is updated every 10 seconds, and the new CW must arrive in advance while the old one is still active. If it is delayed — a few seconds of freeze, then recovery. Users call this "freezing."

Checking ping to the server:ping -c 20 hostname.example.com. Look at the maximum jitter, not the average. Unstable ping is worse than high constant ping.

CAID conflicts and provider-ID mismatch

There can be several CAIDs from different encryption systems (Viaccess, Nagravision, Irdeto) on one transponder. If the wrong CAID is specified in the client's settings, the request will go to the wrong place.

In OScam, you can specify priority inoscam.conf through the section[camd35] or specify the preferred CAID in the dvbapi settings. Sometimes the problem is solved by adding the required CAID to the filtering list — and the server stops trying to decode through the unsuitable reader.

A separate situation is the change of SoftCam.Key when the operator updates the encoding. In CCcam, you need to manually update/usr/keys/SoftCam.Key and restart the daemon. OScam withau=1 automatically updates keys via EMM — but for this, the correct time zone is needed on the receiver. A mismatch in the time zone breaks EMM processing — the card does not receive the rights update, and after a while, channels disappear.

Another case is the simultaneous operation of a local card and a remote line. In OScam, the order of polling readers is set by thereader parameter in the section[account] or through group priorities. By default, OScam will try all readers in the group and select the fastest one. If you want to force the local card to be used first — assign it a separate group with a higher priority.

How to choose a server provider: criteria without names

Before discussing selection criteria — a warning. Connecting to a server with someone else's subscription without the operator's permission violates the terms of service, and in some countries falls under articles on unauthorized access to paid content. This is a real legal risk that should be recognized.

If you are setting up your own card sharing server for your devices with your own card — that’s a different matter. But if it’s about connecting to a third-party provider — I will describe technical criteria, not a call to use specific services.

Stability of uptime and quality of uplink

Claimed uptime of 99.9% — is marketing. The real question is: how often does the server go down at night and on weekends, and how quickly does it recover? This can only be checked during a trial period and on forums.

Uplink quality is more important than speed. A 100 Mbps server with an unstable channel is worse than a 10 Mbps server with solid uptime. Look at the jitter, not the claimed bandwidth.

Geographical proximity of the server directly affects quality. A server in your region will give a ping of 5–20 ms. A server in another country — 80–150 ms. This is critical for HD.

Supported protocols and CAID

Check that the server supports your protocol (CCcam, newcamd) and the CAID you need. A good provider clearly lists supported operators and encryption systems.

If a specific package of channels is needed — clarify availability before payment. Some CAIDs require specific cards, and not every server has them.

Trial period and technical support

Trial access for 24–48 hours is standard. If there is none, it’s a warning sign. During the trial period, check: ECM time (via OScam webif), stability when switching channels, behavior during peak hours (evening, weekends).

Technical support should respond in a reasonable time. If the server goes down on Saturday evening, and support responds on Monday morning — that’s not support. Check contact methods in advance: Telegram, ticket system, or only email.