Card sharing: what it is and how the technology works

If you have ever set up a satellite receiver based on Enigma2, like Dreambox or Vu+, you have probably encountered the terms CCcam, OScam, and "sharing". Many have heard this word, but few understand how it actually works under the hood. Let's figure it out, what card sharing is and how the technology of shared access to paid TV works in reality. It’s not magic, but a quite understandable client-server architecture.

I have been tinkering with these systems for years, from old CCcam 2.1.4 to modern OScam builds, and I can explain the process without marketing fluff. The essence is not in "free TV", but in the shared use of one legal access card.

What is card sharing: the essence of the technology in simple words

At its core is a simple principle: one person buys an official subscription to a package of channels and receives a smart card from the provider. This card is inserted not into the TV, but into a special device—a server (often the same receiver or a small computer like Raspberry Pi), which is connected to the internet 24/7.

Other people (clients) connect to this server over the network. When a client wants to watch an encrypted channel, their receiver does not try to decrypt the signal itself. Instead, it sends a small request (ECM) to the server. The server forwards this request to the physical card, the card generates a key for decryption (Control Word, or CW) and returns it to the server. The server sends this key back to the client. That's it, the picture is on the screen.

The principle of shared use of a smart card

Imagine that you have a master key to all the doors in a building (this is the smart card). And your friends want to enter different rooms. Instead of handing them the master key, you stand at the entrance. A friend approaches, says "I need to go to room 101", you use your master key to open the door and let them in. The key itself does not leave your hands.

It's the same here. The smart card is the "master key". The server is you. And the Control Word is the "action of opening the door". This key, CW, is just 16 bytes of data that change every 10 seconds. The server simply distributes these one-time keys upon request.

How card sharing differs from IPTV and pirate streaming

This is the key difference that many overlook. When using IPTV or pirate streams, you receive the entire video stream over the internet. This requires a wide bandwidth, a stable connection, and the quality depends on how heavily the video signal is compressed on the server.

In card sharing, the video stream comes directly to you from the satellite, cable, or air. In its original, uncompressed quality. The internet is only needed for exchanging tiny keys (ECM/CW). The traffic is minimal, literally kilobytes per hour. You use your own tuner, and the internet only helps to "authorize" it for viewing.

Roles in the system: server, client, card

The system consists of three components:

• Access card: A physical smart card from the provider. It is the source of legitimacy, it is the one that can generate CW.
• Server: A device (PC, receiver) where the card is inserted and where special software (for example, OScam) is running. Its task is to receive requests from clients and query the card.
• Client: Your satellite receiver on which the client part of the software (CCcam or OScam) is running. It receives the encrypted stream, requests the key from the server, and applies it for decoding.

Technical architecture: what card sharing is and how the technology of shared access to paid TV works in practice

Now let's dig deeper. How exactly does this key exchange happen? The entire process consists of several steps and must be completed very quickly, before the key becomes outdated.

The life cycle of the Control Word: from the card to the decoder

Look, here is the full cycle. Suppose you switched to a paid channel.

1. The satellite transponder broadcasts an encrypted stream according to the DVB-CSA standard.
2. Your receiver receives this stream, but cannot display it. It extracts a special packet from the stream—ECM (Entitlement Control Message). This packet contains encrypted information necessary for generating the key.
3. The emulator plugin on your receiver (client) intercepts this ECM packet.
4. The client sends this ECM to the remote card sharing server via TCP/IP.
5. The server receives the ECM, sees which client the request came from, and forwards it to the card reader where the physical smart card is installed.
6. The smart card processes the ECM and generates a 16-byte key in response—Control Word (CW).
7. The server receives the CW from the card and immediately sends it back to the client over the network.
8. The client receives the CW and passes it to the DVB decoder of the receiver.
9. The decoder, using this key, decrypts the video and audio streams. You see the picture.

The entire cycle must occur in less than 10 seconds, because this is the frequency (called the crypto period) at which the provider changes the CW in the stream. If the key does not arrive on time, the picture will freeze.

CCcam protocol: connection structure and ports

CCcam is one of the oldest and simplest protocols. It operates on the principle of "everyone with everyone". The server and client exchange not only keys but also information about the cards they have. The standard port that the CCcam server listens on is 12000 (TCP)It is easy to block with a firewall, so this is the first thing to check when there are problems.

The protocol is quite "chatty" and not the most efficient, but due to its simplicity, it is still popular. Unfortunately, its development was discontinued many years ago, the last official version is 2.3.0.

OScam/CSP protocol: differences and advantages

OScam is not just an emulator, but a whole framework. It can work as both a server and a client, supporting a bunch of protocols simultaneously. OScam can connect to a CCcam server while distributing via the Newcamd protocol.

The main ports you might encounter in OScam:

• Newcamd: Usually in the range of 2000-2020 (TCP). A more efficient protocol than CCcam.
• CCcam: If OScam emulates a CCcam server, it can listen on port 16000 or any other.
• Camd35 (CS357x): Port 2222 (UDP). A fast protocol, but less common.

OScam is actively developed, has a ton of settings, detailed logging, and supports almost all existing cards and encoding systems. In 2024, using CCcam is like driving an antique car. It works, but OScam is better in every way.

Latency and why CW delay is critical

Latency, or ping, is the time it takes for a data packet to travel from your receiver to the server and back. In card sharing, this is the most important parameter. CW changes every 10 seconds. If your ping to the server is, say, 300 ms, then just for the transmission of ECM/CW back and forth, it will take 600 ms. Add to this the time for the server and the card to process the request (another 50-200 ms). In total, it can amount to 800 ms.

This is still tolerable. But if the ping rises to 500 ms, the total time will approach one second, and with any network fluctuations, it may exceed this threshold. The result is freezing of the picture, "breaking" into squares, or the message "channel is encoded." The ideal ping to the server is less than 80 ms.

Configuration formats: CCcam.cfg and oscam.server

Client setup comes down to editing a text file. Nothing complicated if you know the syntax.

Minimal CCcam.cfg configuration for the client

This is classic. The `CCcam.cfg` file is usually located in the `/etc/` directory on receivers with Enigma2. To connect to the server, just add one line:

C: my.sharing-server.net 12000 user123 password456

Where `my.sharing-server.net` is the server address, `12000` is the port, `user123` is your login, `password456` is the password. That's it, nothing more is needed. After saving the file, you need to restart the CCcam emulator.

Structure of oscam.server and oscam.user

OScam is more complex. It has several configuration files, usually in `/etc/oscam/`. The main ones:

• oscam.conf: Global settings for the OScam server itself.
• oscam.server: This describes connections to remote servers (readers).
• oscam.user: This configures client accounts that will connect to your OScam.

Here is an example of a reader configuration in `oscam.server` for connecting to a CCcam server:

[reader]
label                         = my_provider
protocol                      = cccam
device                        = my.sharing-server.net,12000
user                          = user123
password                      = password456
group                         = 1
cccversion                    = 2.3.0

As you can see, OScam can work as a CCcam client. This is the most common use case today.

Parameters reshare and hop-count: what they mean

In the world of CCcam, there is the concept of "depth" or "hops." Hop1 is the card that physically resides on the server you are connected to. Hop2 is the card that your server receives from another server, and so on.

Each hop adds latency. A channel from a hop3 card will almost certainly lag. In the `CCcam.cfg` config, there is a parameter `RESHARE`. If the server gives you a card with `reshare = 0`, it means you can use it, but you cannot pass it on to your clients. If `reshare = 1`, you can pass it one level deeper (your clients will see it as hop2).

Typical mistakes in configs and how to read them in logs

90% of problems are typos. Incorrect port, IP address, login, or password. The second most common problem is the firewall on the router blocking TCP port 12000. The third is that the receiver does not see the config because you edited it in Windows and saved it with incorrect line endings (CRLF instead of LF).

Logs are your best friend. In CCcam, they are usually written to `/tmp/CCcam.log`. OScam has a convenient web interface where in the LiveLog section you can see everything in real time. If you see `ECM timeout` errors, it means the response from the server is not coming in time. If `login failed`, check the login/password.

Conditional Access Systems (CAS): Nagravision, Viaccess, Irdeto, and others

Providers use different encryption systems (Conditional Access System, CAS). The emulator must understand which system it is working with. This is determined by a special identifier — CAID.

Overview of the main CAS systems in Europe and the CIS

Each system has its unique CAID. Here are some of the most common ones:

• Viaccess: CAID 0x0500. Used by many European and Russian providers.
• Irdeto: CAID 0x06xx. A very popular system, for example, among many satellite operators.
• Nagravision: CAID 0x18xx. Historically one of the most popular systems, for which CCcam was created.
• Conax: CAID 0x0B00. Often found in Scandinavia and Eastern Europe.
• BISS: CAID 0x2600. This is not a full-fledged CAS, but a simple system with fixed keys that are often entered manually.

CAID: how the decoder and server identify the encryption system

When the receiver receives an ECM packet, it contains the CAID. The client emulator looks at this CAID and understands which server (or reader) to send the request to. For example, you may have two connections: one for the Viaccess package, another for Nagravision. OScam will intelligently manage which ECM to send where.

If OScam cannot decode the channel, and in the logs you see `(ecm) NOT FOUND`, the first guess is that the CAID of this channel is not supported by your server. Perhaps the server simply does not have a card for this provider.

Compatibility: which cards work with CCcam and OScam

OScam, thanks to its modular architecture, supports almost all existing types of cards through the corresponding reader protocols (pcsc, smargo, internal). CCcam is much more limited in this regard.

But support depends not only on the software. Some new versions of cards from providers may have additional protection that prevents them from working in third-party card readers. This is called "pairing."

What affects the stability of card sharing: practical factors

Even with perfect settings, problems can still arise. Stability depends on three things: your internet, the quality of the server, and the protection from the provider.

Ping to the server and acceptable values

As I mentioned, this is the main thing. Before choosing a server, always check the ping to it. You can do this with the command `ping my.sharing-server.net` in the command line.

• < 80 ms: Excellent. Everything will work stably.
• 80-200 ms: Acceptable. Rare, short freezes may occur during peak network loads.
• > 200 ms: Bad. Stutters will be frequent, viewing will be uncomfortable.
• > 500 ms: Unusable. The picture will appear only occasionally.

Number of clients per card: physical limitations

This is something that sharing sellers remain silent about. A physical smart card is a slow microcomputer. It can only process ECM requests sequentially, one after another. On average, one card can adequately serve 10-15 simultaneous clients without creating a large queue.

If you "hang" 50 clients on one card, then when all of them request a key simultaneously, the last in line will receive it with a huge delay. Hence the problems for many cheap services: they save money by hanging hundreds of users on one card. That’s why it’s so important to understand, card sharing what it is and how the technology of shared access to paid TV works, to choose a quality service.

Provider instability: rolling keys and anti-sharing protection

Providers are constantly fighting against sharing. One of the methods is pairing, or binding the card to the serial number of the official receiver. Such a card simply will not work in another device.

Another method is accelerated key changes (rolling keys) or sending "fake" ECM requests that overload the card and server. Advanced protection systems can make sharing a specific package of channels impossible or very unstable.

When CCcam is better than OScam and vice versa

In 2024, the answer is clear: OScam is better almost always. It is more stable, faster, more flexible, has a web interface for monitoring, and is actively supported by the community.

CCcam can only be justified in one case: if you have a very old receiver for which there is simply no modern version of OScam. In all other situations, I strongly recommend taking the time to understand OScam. It is an investment in the stability of your system.