Card Sharing: what it is and how the CCcam and OScam protocols work

Card sharing is a technology for the simultaneous shared use of a single pay television smart card by multiple subscribers. The physical card remains with the server owner, while other users gain access to encrypted channels over the network. Over the past twenty years, this technology has evolved from homemade computer-based solutions to specialized software supporting dozens of conditional access systems.

How card sharing works

Pay TV channels protect their broadcasts with conditional access systems (CAS — Conditional Access System). Popular ones include: Nagravision, Irdeto, Viaccess, Conax, CryptoWorks, and SECA Mediaguard. Every few seconds (usually every 10 seconds), the content provider changes the encryption key — the so-called control word (CW, Control Word). This word is encrypted in the ECM (Entitlement Control Message) stream and can only be decrypted by the subscriber's legitimate smart card.

In card sharing, the process looks as follows:

1. The client device (receiver or computer) extracts an ECM packet from the satellite stream.
2. This packet is sent over the network to the card sharing server, where the physical smart card is installed.
3. The server passes the ECM to the card, and the card returns the decrypted control word CW.
4. The CW is sent back to the client.
5. The client uses the CW to decode the video stream and display the picture.

This entire exchange takes between 50 and 300 milliseconds. If the delay exceeds the key update threshold (10 seconds), artifacts appear on screen — image freezing or brief blackouts.

The CCcam protocol: architecture and features

CCcam is the most widespread card sharing protocol, developed for receivers based on the Enigma2 operating system (Dreambox, VU+, Gigablue, and others). The protocol operates on a client-server scheme: a CCcam daemon runs on the server and handles incoming requests from clients.

CCcam configuration structure

The server side is configured through the fileCCcam.cfg. Key directives:

• LISTEN PORT — the listening port (default 12000).
• SHARE LIMIT — the maximum depth of card redistribution between servers.
• CAID PRIORITY — the priority of conditional access systems when multiple cards are present.
• CLIENT AUTOCONNECT — automatic reconnection on connection loss.

The client section is stored in the same file, but in theC: (Client) section. A typical connection line looks like this:C: hostname.example.com 12000 username password. The server specifies available resources via linesF: (Fake), which define virtual channels for routing requests.

Cascading in CCcam

One of the key features of CCcam is support for cascades (hop sharing). The parameterSHARE LIMIT determines how many "hops" a card can be passed between servers. With a value of 1, server B can use server A's card, but server C will no longer get access through B. Deep cascades increase latency and reduce stability, so professional setups limit the value to one or two.

Connection encryption in CCcam

The original CCcam uses its own traffic "obfuscation" mechanism based on the SHA1 algorithm and pseudorandom key generation on each connection. This is not full encryption, but rather protection against simple data interception. For serious connection security, it is recommended to route a tunnel via OpenVPN or WireGuard on top of the CCcam connection.

The OScam protocol: a modern alternative

OScam (Open Source Softcam) is an open-source conditional access client/server implementation that has become the de facto standard for modern cardsharing setups. Unlike CCcam, OScam simultaneously supports multiple protocols: camd33, camd35, newcamd, radegast, and CCcam itself. This allows OScam to be used in heterogeneous networks where some devices run on older software.

OScam configuration: four key files

OScam configuration is distributed across several files, each responsible for its own area:

• oscam.conf — global parameters: logging level, web interface settings, file paths.
• oscam.server — description of key sources: physical card readers, remote CCcam servers, or camd35 servers.
• oscam.user — list of clients with logins, passwords, and restrictions (by CAID, by SID, by access time).
• oscam.services — grouping of services (channels) by identifiers for fine-grained access control.

OScam web interface

OScam comes with a built-in web server, accessible by default on port 8888. Through it, the administrator can see in real time: which clients are connected, which ECM requests are being processed, the average response time for each card reader, and error statistics. For example, if the average ECM time for a specific CAID exceeds 800 ms, this is a signal to check the connection quality to the server or replace the physical card.

Load balancing in OScam

The load balancing feature allows OScam to automatically distribute ECM requests among multiple sources. If three servers with cards from the same provider are connected, the system sends requests to the one with the lowest average response time. If one source becomes unavailable, requests are automatically redirected to the backups. This feature is configured via the directivelb_mode in the section[global] of the oscam.conf file. The valuelb_mode = 1 enables load balancing by minimum response time.

Comparison of CCcam and OScam

Performance and Stability

CCcam consumes fewer CPU resources on embedded devices (for example, on older receivers with a MIPS 400 MHz processor), but is less stable under high loads. OScam was written from scratch with multithreading in mind and works significantly more stable with 50+ simultaneous clients. On a modern Raspberry Pi 4 used as a cardsharing server, OScam handles up to 200 simultaneous ECM requests without performance degradation.

Configuration Flexibility

CCcam offers simpler configuration — a single file, straightforward syntax. OScam requires an understanding of a multi-file structure, but gives precise control over every aspect: you can restrict a specific user to only certain channels by SID, set time-based access windows (for example, from 18:00 to 23:00), and limit the number of simultaneous sessions.

Protocol Support

CCcam supports only its own protocol and cannot act as a camd35 or newcamd server. OScam works in both modes — as a CCcam client (connecting to CCcam servers) and as a CCcam server (accepting CCcam clients). This makes OScam a universal gateway between different ecosystems.

Common Issues and Their Diagnosis

Delays and Image "Freezes"

If the picture periodically "freezes" for 1–2 seconds, the cause is almost always a high ECM response time. In OScam this is visible in the web interface: the ECM time value in the ms column for a specific CAID. Up to 500 ms is considered normal. Values above 800 ms require intervention: checking the ping to the server, the quality of the physical card reader, or the communication channel.

Authorization Errors

The errorFAKE in CCcam logs means the server announced the presence of a card but is actually unable to decrypt the request. This occurs during cascading when an intermediate server is unavailable. In OScam, a similar situation is reflected by the statusE: fakecw in the log file. The solution is to reduce the cascade depth or switch to a direct connection to the source.

Issues with Specific Channels

Some channels use multiple CAIDs simultaneously (for example, Sky Deutschland packages are broadcast with CAID 0x09C4 and 0x098C). If the receiver requests a CAID that is not present on the server, the channel will not open. In OScam, CAID priority is set via thecaid directive in the server section, which allows you to explicitly specify which identifier to use for a specific provider.

Hardware and Network Requirements

Almost any Linux-based device is suitable for a cardsharing server: Raspberry Pi 3/4, an old netbook, an Enigma2 receiver, or a VPS in the cloud. Minimum requirements are 256 MB of RAM and a stable channel with a bandwidth of at least 1 Mbit/s. Each active client generates approximately 5–20 KB/s of traffic (ECM packets are small but frequent).

Connection stability is critically important. Providers with dynamic IP addresses create additional complexity: every time the address changes, clients have to reconnect. Using dynamic DNS services (such as No-IP or DuckDNS) solves this problem — the domain name always points to the server's current IP.

Legal Aspects of Cardsharing

The legal status of cardsharing varies by country. In Germany, the Federal Court (BGH) in a 2013 ruling recognized the commercial provision of cardsharing access as a violation of copyright and the terms of the contract with the provider. In Russia, Article 146 of the Criminal Code of the Russian Federation (copyright infringement) is theoretically applicable to the commercial distribution of access to encrypted content. Using the technology for personal viewing of paid content on multiple personal devices exists in a legal gray area, whereas reselling access to third parties clearly violates subscription terms and copyright law.

Alternative Technologies: IPTV and NVOD

With the spread of high-speed internet, cardsharing is gradually being displaced by IPTV services that provide access to the same channels without the need for a satellite dish and specialized equipment. Nevertheless, in regions with unstable internet or in areas where the satellite signal is the primary source of television, cardsharing remains a relevant technology. CCcam and OScam are supported by active developer communities and are regularly updated to work with new versions of conditional access systems.