Eurocardsharing: setting up CCcam and OScam server

Eurocardsharing is a technology for exchanging control words between a physical smart card and remote receivers over the network. If you have already figured out how to receive satellite signals on Enigma2 and want to understand how the ECM → CW → decryption chain actually works, this article is for you. No ads, just configs and commands.

What is eurocardsharing and how does the exchange of control words work

To understand the technical side of eurocardsharing, you need to figure out what happens inside, rather than just blindly copying config lines.

The principle of card sharing: ECM, CW, and decryption

Each encrypted DVB-S2 channel broadcasts service packets of two types along with the video stream: ECM (Entitlement Control Message) and EMM (Entitlement Management Message). ECM contains the encrypted control word — an 8-byte key that decrypts the video. EMM manages the rights of a specific card.

A receiver without an active card cannot decrypt ECM on its own. This is where the server comes in: it receives the ECM request from the client, decrypts it through the physical CAM card, and returns the ready control word. This cycle repeats every 8–12 seconds — providers change CW at their discretion, usually around 10 seconds.

Each card and provider are identified by a pair of parameters: CAID (CA System ID, for example0x0D00 for Cryptoworks or0x0500 for Viaccess) and Provider ID (a six-digit hex identifier of a specific package). If these values do not match between the client request and what the server can service, there will be no decoding, even with a successful login.

The role of the server (card source) and client (receiver)

The server is a machine with a physical card reader (or several) to which a real smart card with a subscription is connected. The server runs CCcam or OScam, listens for incoming ECM requests, and responds with control words. The client — your Dreambox, Vu+, Zgemma, or any other Enigma2 device — connects to the server and requests CW as needed.

The delay between the request and response (ECM time) is a key quality indicator. Up to 400–500 ms is considered normal. More than 800 ms — freezes begin, especially on HD channels with a short CW change interval.

What are the differences between CCcam, newcamd, and MGcamd protocols

CCcam is the most widely used protocol with support for hop-chain and reshare. The default port is 12000. Newcamd (usually port 15000) is an older protocol that works with one card per connection, used in some legacy systems. MGcamd is a lightweight client protocol without a server part, often used on weak receivers.

OScam supports all three protocols plus Camd3, gbox, and others — and can work with multiple cards and readers simultaneously with prioritization. CCcam can only handle its own.

Setting up CCcam server: configuration files and ports

CCcam stores its configuration in one file. On Enigma2 receivers, the path to it is/var/etc/CCcam.cfg. On some images (OpenATV, OpenPLi), the path may be the same, but on custom builds — check where the package was installed.

Files CCcam.cfg and CCcam.channelinfo in /var/etc/

The main file isCCcam.cfg. Additionally, there isCCcam.channelinfo — it contains the mapping of channel names for the web interface and does not affect the decoding process. You do not need to touch it.

Restarting CCcam after editing the config:

/etc/init.d/CCcam restart

Lines F: (local users) and C: (connection to server)

The lineF: creates a local user that clients can connect to:

F: myuser mypassword 1 0 0 0 { 0:0:1 }

Format:F: username password reshare reshare_distance uphops maxdown {caid:provid:serviceid}. If you want to allow everything — set{ 0:0:0 }.

LineC: — this is a connection to a remote server:

C: server.example.com 12000 username password yes

The last parameteryes/no — whether to allow receiving EMM from the server. Usuallyno, if card rights do not need to be updated.

The default port is 12000 and the parameter SERVER LISTEN PORT

By default, CCcam listens on port 12000. It can be changed inCCcam.cfg:

SERVER LISTEN PORT : 12001

The web interface (webinfo) operates on port 16001. There you can view the status of connections, the list of cards, and ECM time in real-time. The port is changed by the parameter:

WEBINFO LISTEN PORT : 16002

The parameters share limits, hops, and reshare

Hop — the number of hops from the physical card to your receiver. Hop 1 means the server holds the card locally. Hop 2 — it receives from someone else. Each additional hop adds delay and instability. Ideally — hop 1.

The parameterreshare in the lineF: (the second numeric argument) determines whether this user can share the card further.0 — prohibited,1 — can share on one hop.

The limit parameters inCCcam.cfg:

SHARE LIMIT : 1

OScam configuration: oscam.server, oscam.conf, and oscam.user

OScam is not just a replacement for CCcam. It is another level of flexibility. When working with multiple cards, multiple readers, or mixed protocols — OScam wins on all counts. The setup is more complex, but once you figure it out, you won't want to go back.

The directory structure /etc/tuxbox/config/oscam/

The standard path for Enigma2 images —/etc/tuxbox/config/ or/etc/tuxbox/config/oscam/. In OpenATV 7.x and OpenPLi 9.x, the configs are usually located in/etc/oscam/. You can clarify the actual path with the command:

find / -name "oscam.conf" 2>/dev/null

Main files:oscam.conf,oscam.server,oscam.user,oscam.services. Each is responsible for its own area.

The [reader] section in oscam.server for the cccam protocol

Example of connecting to a CCcam server via OScam:

[reader]

The fieldcaid restricts which systems this reader will serve. The fieldident specifies the specific provider — this is important when there are multiple cards from different providers on the server and you want to strictly control the routing of ECM.

Ifcaid andident do not match what the server actually sends — OScam will ignore them. This is a common reason for "working connection without decoding."

Configuration of [account] in oscam.user and groups (group)

The link betweenoscam.server andoscam.user goes through the fieldgroup. A reader withgroup = 1 will only be used by accounts that havegroup = 1 inoscam.user:

[account]

If you have multiple readers with different cards and you want to give different clients access to different cards — change the group number. The reader withgroup = 2 will not be visible to the client withgroup = 1. This is an isolation mechanism.

The conflict of multiple readers with the same CAID is resolved by the parametercccam_priority or by explicitly specifyingident in each reader — otherwise OScam selects the first matching one, which is not always optimal in terms of delay.

The web interface is on port 8888 and the section [webif]

Inoscam.conf add:

[webif]

The OScam web interface on port 8888 is a full-fledged monitoring tool: it shows each reader, its status, ECM time, the number of decode/no decode for the session. Much more informative than CCcam webinfo.

OScam logs —/var/log/oscam.log. The level of detail is set inoscam.conf:

[global]

Or when starting from the command line:oscam -d 64. Level 64 means ECM/CW messages without unnecessary noise.

Diagnosing problems: freeze, lack of signal, and connection errors

Most problems with eurocardsharing are solved by one algorithm. Randomly clicking in configs without reading logs is a waste of time.

Reading CCcam logs (port 16001) and oscam.log

The first step is to openhttp://receiver-ip:16001 for CCcam. It shows: whether the receiver is connected to the server (status connected/disconnected), a list of available cards with CAID, and ECM time for the latest requests.

In the OScam logs, look for lines like:

2026/01/15 14:23:05  c  username  0D00&000000/0000/0020/00 2 ms  decode ok

Or problematic ones:

2026/01/15 14:23:05  c  username  0D00&000000/0000/0020/00 850 ms not found

850 ms with "not found" means either an incorrect ident, the server is overloaded, or the reader is unavailable.

Freeze of channels: ECM time and network delay

Freezing every 8–12 seconds is almost always a symptom that the new CW does not arrive in time before the change. Diagnostic chain:

1. Check ECM time in the web interface. The norm is up to 400–500 ms. If it's more than 700 — the source is far away or overloaded.
2. Ping the server IP:ping -c 10 server-ip. A ping above 150 ms on a poor channel guarantees problems on HD channels.
3. Check hop in CCcam webinfo. Hop 3 and above on an unstable channel is a recipe for constant freezes.

HD channels freeze earlier than SD for another reason: some providers have a shorter CW change interval on HD streams — sometimes 7–8 seconds instead of 10. The buffer is smaller, and even 600 ms ECM time is already critical. SD works under the same conditions — hence the illusion of "SD works, HD does not."

Error connecting / login failed: check port and firewall

Login failed with the correct login/password — first, check the firewall.

Check if CCcam is listening on the port:

netstat -tlnp | grep 12000

Open the port through iptables:

iptables -A INPUT -p tcp --dport 12000 -j ACCEPT

If the receiver is behind the provider's NAT (especially common with 4G/LTE or "gray" IPs) — the port is not accessible from the outside at all. Check the external IP:curl ifconfig.me. If it matches the router's IP — port forwarding can be set up. If not (double NAT from the provider) — a VPN or reverse tunnel is needed.

Network ECM problem and incorrect caid/provider

Situation: connection is successful, cards are visible in webinfo, but decode is not happening. This is a classic mismatch of CAID or Provider ID. The server accepts the ECM request, but the card does not understand it — returns "not found."

In the OScam logs, this appears as constant linesno matching reader orno card. Solution: verify CAID and ident inoscam.server with the actual values that the channel broadcasts. They can be viewed in Enigma2 through the Service Info plugin or directly in the OScam logs at debug level 255:

oscam -d 255 2>&1 | grep -i caid

How to choose a reliable source: technical criteria

When dealing with eurocardsharing, sooner or later the question arises: how to distinguish a good source from a bad one without having access to it in advance. There are several objective parameters.

Server uptime and ECM time stability

Uptime is a necessary but insufficient criterion. A server can be online 99% of the time, but with an ECM time of 900 ms — using it will be a torment. Request a trial period from the provider and monitor ECM time through OScam webif during this time. Stability is more important than the average value: ECM time of 300 ms ± 50 ms is better than 200 ms with spikes up to 1200 ms.

Local card (local) vs reshare (reshare)

This is perhaps the most important technical criterion. A local card (local) means that the physical card is inserted directly into the server you are connecting to. Hop 1. Reshare (reshare) — the server itself is a client of someone else's server and simply resells access. Hop 2, 3, and above.

Each additional hop adds delay and a point of failure. A source on a reshare hop 3 with three parallel clients at each level is a real overload. Ask directly: local card or reshare? If the answer is evasive — it's likely a reshare.

Support for the required caid and provider

Make sure that the server really supports your CAID and specific Provider ID. These are not the same: a card may be Viaccess (CAID 0500), but from a package that does not include the required channels. Request a list of supported CAID:ident before connecting.

A common mistake is to see the CCcam webinfo card with the desired CAID, but the channels are not decoded because the Provider ID is different. Check the pair specifically.

Geographical proximity and network latency

Ping to the server directly affects ECM time. A server in Germany with a ping of 15 ms will give an ECM time of 100–150 ms. The same server with a ping of 120 ms through a bad route will have an ECM time of 600+ ms. Geo-proximity is important, but the quality of the route is more important.

Check before connecting:traceroute server-ip. If there are more than 12 hops in the route or there is a hop with a delay of 80+ ms — this is a signal. A good source on another continent with a bad route is worse than an average source nearby.