Cardsharing server: setting up CCcam/OScam from scratch (2026)

If you've reached the stage where you want to set up your own cardsharing server instead of relying on someone else's — this article is for you. There will be no marketing here. Only real architecture, specific configs, and diagnostics of what is going wrong.

I assume you already have an Enigma2 receiver or DreamBox, a VPS or a home machine running Debian/Ubuntu, and you understand basic Linux commands. We'll figure out the rest.

What is a cardsharing server and how does it work

Most articles provide ready-made configs without explaining what happens under the hood. This is a mistake — without understanding the architecture, you won't be able to diagnose problems.

Architecture: receiver → softcam client → server → smart card

The satellite stream comes encrypted. The receiver receives ECM (Entitlement Control Message) — an encrypted packet containing keys to decrypt the current frame. The softcam on the receiver (oscam-emu, NCam, CCcam client) intercepts this ECM and sends it via TCP to the server.

The server sends the ECM to the physical smart card through a reader (Phoenix, SmartReader+, Internal). The card returns DCW (Descrambling Control Word) — an 8-byte key. The server sends the DCW back to the client, and the receiver decrypts the stream.

Norm: ECM time 150–400 ms. At >900 ms, freezes begin — the stream changes CW before the receiver can get a new one.

Exchange protocols: CCcam, newcamd, CS378x, MGCamd

CCcam (port 12000 by default) — the most common, but proprietary. Newcamd (port 15050) — an old protocol with DES encryption, used for compatibility. CS378x (port 22222) — more modern, fewer known fingerprints, a good alternative to CCcam for new installations. MGCamd works on top of newcamd.

What are ECM, EMM, and DCW in the DVB stream

ECM (Entitlement Control Message) — a request for the decryption key, changes every 10–30 seconds. EMM (Entitlement Management Message) — messages updating the card's rights, come less frequently, update entitlements. DCW (Descrambling Control Word) — the result of the card's work, the actual decryption key for the stream.

If the card does not receive EMM updates, it will gradually lose rights to channels. That is why the parameterau=1 in the reader's config is important for long-term operation.

The role of CAID and provider ID when selecting a channel

CAID (Conditional Access ID) defines the encryption system: 0500 — Viaccess, 0B00 — Conax, 1801 — Nagravision/Nagra3, 0604 — Irdeto, 0100 — SECA Mediaguard. Provider ID — a specific operator within this system. OScam routes ECM to the required reader based on the CAID:ProviderID pair.

Choosing software: CCcam vs OScam vs NCam

Short answer: in 2026, for a new server, choose OScam. Arguments below.

CCcam 2.3.2 — closed, outdated, but still widespread

CCcam was last seriously updated in 2012–2013. Closed source, no support for modern CAIDs, no active developer community. The only reason to use it now is clients with very old receivers that only support the CCcam protocol and haven't been updated for years.

OScam (oscam-svn) — open source, actively maintained

Open code, regular commits in SVN trunk, support for Conax, Nagra3, Viaccess 6, Irdeto2, PowerVu. Memory consumption: ~30–60 MB RAM for 10 simultaneous clients. This is really low — even a VPS with 512 MB will manage. Configs are read from text files, easy to version in git.

NCam — a fork of OScam with extended support for modern CAIDs

NCam is actively developed by the community and gets support for new EMM formats faster. If you need fresh CAIDs — Nagra 4, CardGuard, Irdeto Cloaked CA updates — NCam may outpace OScam trunk by several weeks. API and configs are compatible with OScam.

When to choose what: compatibility, load, EMM updates

OScam — the standard choice for a new cardsharing server with 1–20 clients. NCam — if you need modern CAIDs and are willing to keep a closer eye on updates. CCcam — only if clients physically do not support other protocols and cannot be updated.

Installation and basic configuration of OScam on Debian/Ubuntu

Building from source

Repository packages of OScam are usually outdated. Build from SVN:

apt install build-essential libssl-dev libpcsclite-dev pcscd \
  libusb-1.0-0-dev cmake subversion -y

svn co https://svn.streamboard.tv/oscam/trunk oscam-svn
cd oscam-svn
./config.sh --enable all
make -j$(nproc)

The binary will appear inDistribution/. Copy it to/usr/local/bin/oscam and make itchmod +x. For quick building with default options, you can use./simplebuild ./s.

Configuration structure: /usr/local/etc/ or /etc/tuxbox/config/

By default, OScam looks for configs in/usr/local/etc/. You can override it with the flag-c /path/to/config at startup. File structure:

• oscam.conf — global settings, WebIF, logging
• oscam.server — description of readers (physical cards)
• oscam.user — client accounts
• oscam.dvbapi — for local decoding on the same receiver

oscam.conf — global parameters for WebIF and logging

[global]
nice = -1
logfile = /var/log/oscam/oscam.log
maxlogsize = 512
preferlocalcards = 1
saveinithistory = 1

[webif]
httpport = 8888
httpuser = admin
httppwd = ChangeMe2026
httpallowed = 127.0.0.1,192.168.0.0-192.168.255.255

[cs378x]
port = 22222

[newcamd]
port = 15050@0B00:000000

[cccam]
port = 12000

Changehttppwd to something real. WebIF is available on port 8888 and provides a complete picture: current ECM, reader status, active clients.

oscam.server — description of readers (physical cards)

More details in the next section. The file describes each physical reader and card in it.

oscam.user — client accounts

Each client is a separate section[account] in this file. Created manually or through WebIF.

oscam.dvbapi — for local decoding

Needed only if OScam is running on the receiver itself and decoding locally. Not needed in a server scheme.

Reader setup and smart card connection

Types of readers: Phoenix, SmartReader+, Omnikey, Internal

Phoenix is the cheapest option, connects via COM port or USB-to-COM adapter. SmartReader+ and SmartReader USB are more reliable, working directly through libusb without pcscd. Omnikey 3121 is PCSC-compatible, works well through pcscd. Internal is a built-in reader in some receivers.

Device identification: lsusb, dmesg, /dev/ttyUSB*

lsusb                    # посмотреть USB устройства
dmesg | grep -i smart    # kernel сообщения о ридере
ls /dev/ttyUSB*          # serial USB устройства
pcsc_scan                # сканирование PCSC-устройств, покажет ATR карты

The card type and provider are determined by ATR (Answer To Reset). Ifpcsc_scan does not see the card — checksystemctl status pcscd.

Section [reader] in oscam.server: example for Conax/Viaccess

Example for Conax via SmartReader+:

[reader]
label        = CONAX_CARD1
protocol     = smartreader
device       = Serial:DB00XXXX
caid         = 0B00
detect       = cd
mhz          = 600
cardmhz      = 368
group        = 1
emmcache     = 1,3,2,0
au           = 1

Example for Viaccess via Phoenix (ttyUSB0):

[reader]
label        = VIACCESS_CARD
protocol     = phoenix
device       = /dev/ttyUSB0
caid         = 0500
mhz          = 600
cardmhz      = 600
group        = 1
emmcache     = 1,3,2,0
au           = 1

Mhz, cardmhz, deprecated parameters — typical mistakes

mhz — frequency of the reader,cardmhz — frequency of the card. For Viaccess and Conax usuallymhz=600, cardmhz=368 orcardmhz=357 for Irdeto. If incorrect values are specified, the card will respond slowly or may refuse to work at all. The parameterdeprecated=1 in old configs now causessegfault in recent versions of OScam — remove it.

Checking card ATR via pcsc_scan

Card with readable ATR, but returningcard not subscribed — this is a normal situation when the provider has changed entitlements. A fresh EMM is needed. Enableau=1 in the reader section and let the card work for a few hours — entitlements will update automatically from the stream.

Client sharing: optimal configuration and security

Section [account] in oscam.user: au, group, caid, ident

[account]
user         = client1
pwd          = StrongPass2026
group        = 1
au           = CONAX_CARD1
caid         = 0B00
ident        = 0B00:000000
numusers     = 2
cccmaxhops   = 1
cccreshare   = 0
expdate      = 2026-12-31

Parameterau indicates through which reader this client receives EMM updates.group must matchgroup in the reader section — otherwise you will getrejected group in the log.

Limits: numusers, sleep, suppresscmd08

numusers=2 means that one account can be used with a maximum of two receivers simultaneously.sleep=60 disables the account after 60 minutes of inactivity — useful for limiting resources.suppresscmd08=1 hides information about available CAID from the client.

Protection against resharing: cccmaxhops, cccreshare, hostname

cccreshare=0 — critically important. Without it, the client can reshare your card further down the CCcam chain. Set this for all accounts without exception.cccmaxhops=1 ensures that the client sees only first-level cards. If one account opens 100+ ECM per minute from different IPs — this is a clear resharing, monitor through WebIF.

Tunneling through CS378x instead of CCcam

CS378x on port 22222 is less known to scanners and has built-in encryption. For clients that support CS378x (most modern softcams), this is the best choice in terms of server privacy.

Logging and monitoring through WebIF (port 8888)

WebIF shows in real-time: ECM time for each client, status of readers, number of requests. If you see an account with an abnormally high number of ECM — this is either a bug in the client's softcam or resharing. You can block it directly from WebIF without restarting OScam.

Diagnosing problems: freezes, empty ECM, no card

Most problems with the card sharing server are visible in the log if you know what to read.

Reading oscam.log: response codes 00, 01, 02, E2

Command for live monitoring:

tail -f /var/log/oscam/oscam.log | grep -E 'ECM|EMM|reader|error'

Card response codes:00 — success, DCW received.01 — the card does not have rights for this package.02 — no response from the card (timeout).E2 — CW not found, most often the card is not authorized for this channel.

ECM rejected, card not found, timeout — what they mean

rejected group — check thatgroup inoscam.user andoscam.server match.card not inserted — pcscd does not see the card: check the reader cable and power.no card — the reader is connected, but the card is not inserted or not readable.

High ECM time (>500ms): causes and solutions

If ECM time is consistently >500 ms — look for the bottleneck: high ping between the client and server (>100 ms adds delay), overloaded reader (one card cannot handle 15+ simultaneous requests), incorrectmhz/cardmhz slows down communication with the card. Normal load: 8–10 active clients per card.

The problem 'cw not found' on specific channels

If one specific channel causes freezes while others work — it is likely an EMM-only packet: the channel requires fresh entitlements that the card has not received. Check thatau=1 is enabled and that the card is actually receiving EMM from the stream (there should be lines in the log withEMM written).

Rewriting Nagra3/Conax EMM and key lifespan

Nagra3 and Conax periodically rotate keys via EMM. If the card has not received the stream for several days — the keys become outdated. Solution: connect the card to a live stream with the required CAID for several hours. The problem also occurs when moving the card between readers —emmcache needs to be reset: delete/tmp/.oscam/emmcache.

Two readers with the same CAID conflict during ECM routing — addlb_mode=1 to the section[global] oscam.conf for automatic load balancing.

Choosing a card sharing provider: evaluation criteria

If it is not possible to set up a fully autonomous card sharing server with physical cards, some use external CCcam/CS378x lines. Here, the main thing is not to fall for junk.

Type of cards: local vs virtual (server-emu)

Local cards — physical smart cards in the reader, receive real EMM. Emulation (server-emu with SoftCam.Key) works only for channels with fixed keys (BISS, PowerVu without pairing, some FTA). For modern paid CAID with regular key rotation, a real card is needed.

Number of hops and stability uptime

Hop 1 — you are connected directly to the server with a physical card. Hop 2+ — between you and the card there is one or more resellers. Each extra hop adds 100–200 ms to the ECM time. Insist on demonstrating hop count in WebIF before payment.

Supported CAID and packages

Request a specific list of CAID:0500, 0B00, 1801, 0604 — not "all European channels." Ask for a test line for 24–48 hours and check ECM time via WebIF. A stable value<300 ms is normal. If ECM time jumps from 200 to 1500 ms — unstable reader or overloaded server.

Protection against ECM-flood and DDoS

A serious card sharing server should have rate limiting on ECM requests. Ask if there is protection against a situation where one client floods the server with thousands of ECM — this overloads the card and can be a deliberate attack.

Trial period and technical support

Red flags: "all channels of the world" without specifics on CAID, payment only in crypto without the possibility of a refund, support responds with templates without technical details. Green flags: they name specific CAID and providerID, are ready to show WebIF statistics, respond to technical questions substantively.

Legal and technical limitations

This needs to be stated clearly.

Card sharing of someone else's subscriptions is a violation of the provider's terms and legislation.

The distribution of DCW from a paid subscription to third parties violates the terms of the contract with the operator and the legislation of most jurisdictions: DMCA in the USA, EU Copyright Directive in Europe, Article 273 of the Criminal Code of the Russian Federation (creation and distribution of malicious programs) and Article 272 (unauthorized access to protected computer information) in Russia. Operators actively cooperate with law enforcement agencies.

Legal scenarios: one family, one subscription, multiple receivers

Local OScam for sharing one subscription among several receivers in one apartment is what the technology was originally created for and is in a gray area or clearly legal in most countries. One subscription, one address, multiple TVs — this is normal.

Use for research and educational purposes

Studying ECM/EMM protocols, testing the DVB stack, reverse engineering for academic purposes — this is another area regulated separately. The context of use is important here.

Changes in Nagra3 / Irdeto Cloaked CA — how it affects

Modern protection systems make mass sharing technically impossible. Nagra Anti-Cardsharing encrypts DCW with the specific receiver's key through pairing: CW obtained by one receiver is useless for another. Irdeto Cloaked CA works similarly. Conax v7 with pairing — DCW is encrypted with the specific device's key, extracting the pairing key without physical access to the receiver is unrealistic. This is not theory — most major European packages have already switched to paired delivery.

A client through a mobile network with CGNAT (the operator uses a shared IP for thousands of subscribers) will not be able to receive incoming connections. The solution is a reverse tunnel through autossh or WireGuard VPN, where the client initiates the connection to the tunnel server.