What is CCcam: the card sharing protocol in simple terms

What is CCcam in simple terms

Definition of the CCcam protocol

In short: what is CCcam — it is a client-server protocol that allows multiple satellite receivers to use one pay TV smart card over a network. The client receiver connects to the server, where the physical card is inserted, and receives data for decrypting the channel from it. Without its own card in the slot.

This is receiver-level software — not a service, not a website, not a device. CCcam is installed on a satellite receiver running Linux (most often Enigma2) and either serves its local card to others or connects to someone else's server for decryption data.

What task does card sharing solve

There is one task: one subscription — multiple viewing points. The card owner starts a server, and others connect as clients. Technically, this is calledcard sharing — shared card usage.

Implementation via CCcam looks like this: the server holds the card in a CI slot or smart card reader, accepts encrypted requests from clients, queries the card, and returns the decryption key. All this happens in seconds and is invisible to the user.

Who developed CCcam and its status today

CCcam was developed by an anonymous author under the nickname CC and for a long time was the de facto standard in the satellite enthusiasts community. The protocol is closed — the source code has never been published. This is its main limitation.

There is currently no active development of CCcam. The last known versions were released several years ago. Nevertheless, the protocol is still supported by most server software and receivers on Enigma2. OScam, Wicard, and other emulators can work with the CCcam protocol in compatibility mode. So the question "what is CCcam" remains relevant even in 2026.

How the CCcam protocol works: client-server architecture

Server, client, and the concept of hop

The basic scheme: the server is a receiver or Linux machine with a physical smart card. The client is your receiver that watches channels. Between them is a TCP connection via the CCcam protocol.

Hop is the number of request transfers between nodes until it reaches the actual card. If the server holds the card and you connect directly — that is 1 hop. If server A gets data from server B, and B from server C with the card — that is already 3 hops.

More than 2 hops — practically guaranteed freezes on HD channels. The request for ECM decryption must return faster than the decoder loses the stream. In practice, the window is no more than 2-3 seconds, and each extra node consumes 100-300 ms.

Exchange of ECM/EMM packets

The encoded satellite signal contains special packets — ECM (Entitlement Control Message). These are encrypted messages that carry the control word for decoding the current video stream. Without their decryption — a black screen.

The CCcam client extracts ECM from the transport stream and sends it to the server. The server forwards the ECM to the smart card. The card decrypts it and returns a response. This cycle repeats every 10-30 seconds depending on the broadcaster — this is the frequency at which the control word changes.

EMM (Entitlement Management Message) — another type of packet, they update the rights on the card. In the context of card sharing, EMM usually passes on the server, clients do not receive them.

What is DCW and how does decryption occur

DCW (De-scrambling Control Word) — this is the key that the card issues in response to ECM. Two 8-byte numbers (even and odd key), which the hardware descrambler in the receiver uses to restore the video stream.

The server receives DCW from the card and sends it to the client over the encrypted CCcam connection. The client passes the DCW to the CSA descrambler of its tuner. The channel opens. The entire chain from ECM to open video is within 500 ms under normal connection.

If the DCW arrives late — one of the classic sources of freezes: the decoder is already waiting for a new key, and the old one has expired.

Local cards and reselling (downstream/uplevel)

In CCcam terminology, there are concepts of uplevel (higher-level server) and downstream (lower-level client). A server can simultaneously be a client of another server and serve its clients — this is the resell scheme.

A local card in the CCcam configuration has distance 0 and hops 0. Resell cards obtained from uplevel servers are shown with hops ≥ 1. The client, when connecting, sees a list of available cards and their hop distance — this helps choose which card to use for a specific channel.

Ports, configuration files, and connection string format

The standard CCcam port (12000) and its change

By default, CCcam listens on port12000. This is specified in the config via the directiveSERVER LISTEN PORT : 12000. The port can be changed — many servers use non-standard values like 12001, 15000, or 16000 to bypass provider-level blocks.

If port 12000 is closed by your internet provider — try port forwarding through a non-standard port or VPN. This is a common problem for mobile internet users and some cable TV operators that cut P2P traffic.

On the server behind NAT for receiving incoming clients (lines F:) you need to forward the port on the router. Without this, you won't be able to connect to the server from the outside — it simply won't respond.

File CCcam.cfg and its location

On Enigma2 receivers, the config is located in/var/etc/CCcam.cfg. In some builds — in/etc/CCcam.cfg. If the file is not found — try both paths via FTP client (FileZilla, WinSCP) or Telnet.

It is edited with a regular text editor. After changes, you need to restart CCcam — through the plugin menu in Enigma2 or with the command/etc/init.d/CCcam restart via SSH. In new firmware, the path may differ — check viafind / -name CCcam.cfg 2>/dev/null.

Lines C: (client) and F: (server/friend)

Connection line to the server (client side):

C: hostname port username password [hops]

Example structure — only for illustration of syntax:

C: example.server.com 12000 myuser mypassword

Line F: is an invitation for clients to your server (friend line):

F: username password [hops [au [shared card info]]]

Each line F: creates one account for connection. The number of F: lines equals the number of clients that can be connected to the server simultaneously. These are not parallel sessions — each F: line is unique.

Parameters: hostname, port, username, password, hops, distance

Breakdown of each parameter of line C::

• hostname — IP address or DNS name of the server
• port — TCP port of the server (usually 12000)
• username — account name issued by the server
• password — account password
• hops — maximum number of hops for cards that you want to receive from this server (optional, default is 1)

Parameterdistance in server settings determines how many hops to increase the counter when retransmitting cards further. Set distance 1 for regular resale — then your clients will see a card with one more hop than you.

CCcam vs OScam: what's the difference

The closed nature of CCcam and the openness of OScam

This is a fundamental difference. CCcam is a proprietary binary without source code. OScam (Open Source CAM) — fully open code, repository on Streamboard SVN, builds for each platform.

The closed nature of CCcam means: no protocol-level logs, no ability to patch bugs, no support for new CAID without updating the software itself. And there have been no updates for a long time. OScam is updated regularly — new CAID, new features, fixes.

Protocol support

CCcam works only with its own protocol. OScam can do everything: newcamd, CCcam, mgcamd, radegast, ghttp, cs378x. This means that OScam can connect to a CCcam server as a client, serve CCcam clients as a server, and at the same time maintain newcamd connections.

In practice, the scheme "OScam as a local server + external CCcam lines" works excellently. OScam receives cards via the CCcam protocol from upstream, distributes them to its clients through any supported protocol. This is flexible.

Stability, logging, and web interface of OScam

The web interface of OScam runs on port8888 (configured in/etc/oscam/oscam.conf through the section[webif]). It shows all connected clients, card status, ECM/DCW statistics, and error history.

Logging in OScam is much more detailed. The file/etc/oscam/oscam.log logs every ECM request with CAID, provider, response time in milliseconds, and status. Diagnosing freezes from this log can be done in minutes.

CCcam logs minimally — only connections and gross errors. What exactly happens with a specific CAID is hard to understand.

When to choose which emulator

CCcam — if you need to quickly set up a client on old hardware, minimal settings, everything out of the box. Line C: in the config, restart — done. Works well as a simple client.

OScam — if you need a server with multiple cards, multiple protocols, detailed control, and proper monitoring. Configuration is more complex, but the configuration files (/etc/oscam/oscam.server,oscam.user,oscam.services) provide complete control over every aspect of operation.

A mixed scheme also works: OScam on the server, CCcam on client receivers. OScam serves CCcam clients without problems.

How to choose a server for connection: criteria

Uptime and ping to the server

The first thing to check is the ping. The commandping hostname will show the basic latency. Less than 30 ms — good. 30-80 ms — normal for most channels. More than 100 ms — risks on HD with frequent key changes.

The server's uptime can be indirectly checked through monitoring: trytelnet hostname port several times at different times of the day. If the connection is established consistently — the server is working. If it connects intermittently — that’s already a characteristic.

A test line is a normal practice before purchase. A decent server provides a test for 24-48 hours. During this test, watch not only the picture but also the behavior on HD channels during prime time when the load on the card is maximum.

Minimum number of hops to the card

This is critical. When connecting in the CCcam or OScam webif menu, cards are visible with their hop distance. Ideally — 1 hop (the card is directly on the server). Acceptable — 2 hops. With 3 hops or more on HD channels with 10-second key changes, freezes are almost guaranteed.

Ask the provider directly: are the cards local or resell? How many hops? An honest answer is a good sign. "Local cards" without confirmation through webif — just words.

Stability of DCW and frequency of freezes

Freezes are the main indicator of server quality. The sources can be different: high ping, overloaded card, too many parallel connections to one card, unstable internet of the server itself.

Check on problematic channels: Biss-encrypted channels, channels with frequent key changes (some broadcasters change DCW every 5-7 seconds). If everything is clean on such channels — the server is good.

In the OScam logs, the response time for ECM is displayed in milliseconds. The norm is up to 500 ms. If you see 1000+ ms, the server is struggling with the load.

Transparency of conditions and support for protocols

A good server clearly indicates: which CAIDs are supported, what the limit of simultaneous connections is, whether only CCcam is supported or also newcamd. If this information is missing, it is difficult to diagnose problems.

Special attention: if the channel does not open, although the DCW is coming — check the CAID. The card may not support a specific provider or package. This is not a CCcam bug — it is a limitation of the subscription on the card. Check through OScam webif: see which CAIDs are available on the server.