Satellite TV Card Sharing: How CCcam & OScam Work in 2026

Satellite tv card sharing has been around for over 20 years, and the core technology hasn't changed much — but the tooling has gotten significantly more mature. If you've landed here because someone mentioned CCcam or OScam and you have no idea what those actually do, this is the breakdown you need. We'll go through the full request lifecycle, actual config file structure, and what happens when things break — without the marketing fluff.

This is a technical explainer. It covers how the protocols work, how to configure the software, and how to diagnose problems. If you're looking for a provider recommendation, this isn't that article.

What Satellite TV Card Sharing Actually Is

At its core, satellite tv card sharing is a system for forwarding decrypted Control Words (CW) from a server that has a real smartcard to client receivers that don't. The server holds a legitimate paid subscription card. When an encrypted channel needs to be decoded, the client sends the scrambled ECM packet to the server, the server's smartcard decrypts it, and the resulting CW comes back to the client. The client uses that CW to descramble the video in real time.

That's it. The rest is implementation details.

Conditional Access Systems (CAS) in plain terms

Pay-TV broadcasters use Conditional Access Systems to make sure only paying subscribers can watch. The most common systems you'll encounter on European satellites are Viaccess (CA ID 0500), Nagravision (CA ID 1800/1801), Irdeto (CA ID 0600), Conax (CA ID 0B00), Videoguard (CA ID 0900), and BISS (CA ID 2600). Each has its own encryption scheme and key rotation schedule.

When your receiver locks onto a channel, it pulls the ECM packets from the transport stream. Those packets contain the scrambled Control Word for the current 10-second crypto window. Without a valid CAS subscription, you can't decrypt them.

The role of the smartcard and CAM module

The smartcard is a physical chip card issued by the broadcaster. It holds your subscription entitlements and the private keys needed to decrypt ECMs. In a direct subscription setup, you push the card into a CAM (Conditional Access Module) — a CI module that slots into your receiver. The CAM handles all decryption locally.

In a card sharing setup, the smartcard sits in a card reader connected to the server machine, not in your local CAM. A softcam (software implementation like OScam or CCcam) running on the server or on your receiver handles the protocol exchange.

Why sharing exists: one card, multiple receivers

The legitimate use case is a household with multiple receivers but a single paid subscription. One room has a server with the card; every other TV in the house runs as a client. Many satellite enthusiasts also use card sharing setups for testing CAS implementations in lab environments or for research. These are the non-controversial use cases. Commercial resale of sharing access is a different matter entirely — covered in the legal section below.

Card sharing vs IPTV vs free-to-air: key differences

IPTV streams video over the internet as HLS or RTSP. Card sharing doesn't stream video — it only forwards the 8-byte Control Word needed to descramble a channel you're already receiving via satellite. The actual video comes through your dish and coax cable. Free-to-air (FTA) channels need no decryption at all.

Card sharing has lower bandwidth overhead than IPTV because you're not streaming video data. You're just exchanging small cryptographic packets — ECMs are typically under 200 bytes.

How CCcam and OScam Protocols Work Under the Hood

Here's the actual request flow when you tune to a scrambled channel:

1. Your tuner locks onto the transponder and starts pulling the transport stream
2. The receiver extracts the ECM packets from the stream (PID varies per channel)
3. The softcam client sends the ECM to the card sharing server over TCP
4. The server forwards it to the smartcard reader
5. The smartcard decrypts the ECM and returns the Control Word
6. The server sends the CW back to your client
7. Your receiver's descrambler uses the CW to decode the video

This entire round-trip needs to complete within the 10-second crypto window — ideally in under 500 ms.

ECM and EMM packets: what the receiver actually requests

ECMs (Entitlement Control Messages) carry the scrambled CW. Every channel sends these constantly in the transport stream. EMMs (Entitlement Management Messages) are different — they carry subscription data that updates the smartcard's entitlements. EMMs are how the broadcaster tells your card you've paid for a particular package, or pushes a key update.

If a server has AU (Auto Update) enabled, it forwards EMMs from the transport stream to the card, keeping entitlements fresh. Without AU, cards eventually go stale when the broadcaster rotates keys — you'll see CARDOK but no decoding.

Control Word lifecycle and the 10-second crypto window

The CW rotates every 10 seconds. The transport stream actually carries two CWs simultaneously — the current one (odd) and the next one (even) — so the receiver can pre-buffer. This means you have a brief grace period. But if the new CW arrives after the old one expires, you get a visible freeze that lasts until it shows up.

At 1500 ms ECM time, you're cutting it very close. At 2000 ms, you'll freeze visibly on every rotation. At 500 ms or under, you'll never notice anything.

CCcam protocol: C-line structure and hop count

CCcam is closed-source but its protocol is well-documented through reverse engineering. Client connections are defined by C-lines in /var/etc/CCcam.cfg:

C: hostname 12000 username password

That's it for the client side. The server address, port (default 12000 TCP), and credentials. CCcam handles protocol negotiation from there.

Hop count in CCcam indicates how many servers a card has passed through. Hop 1 means the CW is coming directly from the machine holding the physical smartcard. Hop 2 means someone else is resharing hop 1. Each hop adds latency — roughly 30–100 ms per hop depending on server load and routing. Hop 3 or higher usually causes noticeable freezes on channels with tight timing budgets.

OScam protocol: reader, account, and DVBAPI flow

OScam is open-source and modular. It splits configuration across multiple files: oscam.conf, oscam.server, oscam.user, oscam.dvbapi. Each component has a specific job.

The flow on a server: a reader in oscam.server connects to the physical card. Users defined in oscam.user get access to specific reader groups. The DVBAPI interface handles local descrambling on the same box if needed.

OScam's web interface on port 8888 gives you real-time stats: ECM times, reader status, active connections. This is where you actually diagnose problems.

Newcamd, MGCamd, and CS378x compared

Newcamd (default port 15000 TCP) is an older protocol, still widely supported. It's simpler than CCcam and works fine for basic setups. MGCamd is a softcam client that supports multiple protocols including Newcamd and CCcam — it's popular on older Enigma2 images.

CS378x (default port 10000 TCP) is a newer protocol used by OScam. It's more efficient and adds features like card data caching. If both server and client run OScam, CS378x is worth using. DVBAPI runs on port 2000 as a Unix socket or TCP and is the interface between OScam and the actual hardware descrambler in your receiver.

Setting Up an OScam Server: Configuration Files Explained

OScam config lives in /etc/oscam/ on most Linux setups, or /etc/tuxbox/config/ on Enigma2 boxes. The key files are oscam.conf, oscam.server, oscam.user, and oscam.dvbapi. Get these right and everything else follows.

Directory layout: /etc/tuxbox/config/ vs /var/keys/

On a standard Debian/Raspbian server: /etc/oscam/ for all config files, /var/log/oscam/ for logs. On Enigma2 images (Dreambox, Vu+), config is typically at /etc/tuxbox/config/. Some images mount this on a read-only filesystem with an overlay — in that case writes go to a tmpfs and don't persist across reboots unless you put your config on the data partition. Key files (SoftCam.Key for EMU builds) usually go in /var/keys/.

oscam.conf: global settings, web interface, log paths

[global]logfile = /var/log/oscam/oscam.logmaxlogsize = 512clienttimeout = 5000failbantime = 600failbancount = 5[webif]httpport = 8888httpuser = adminhttppwd = changethishttpdyndns = 0

The clienttimeout value is in milliseconds — how long OScam waits for an ECM response before timing out. 5000 ms is a sane default. Lower values like 2000 ms will cause failed decryptions on slow links but make failures fail fast rather than hanging.

oscam.server: defining card readers (internal, smargo, phoenix)

[reader]label = mycard_viaccessprotocol = internaldevice = /dev/sci0caid = 0500detect = cdmhz = 357cardmhz = 357group = 1emmcache = 1,3,10log-transmit = 0

The protocol = internal line is for built-in card readers on satellite receivers. For USB Phoenix readers, use protocol = phoenix and device = /dev/ttyUSB0. Smargo readers use protocol = smartreader.

The mhz value is the clock speed in 10kHz units. 357 = 3.57 MHz, which is the standard ISO/IEC 7816 clock. Some cards — particularly older Nagravision cards — require 600 (6 MHz) for proper ATR negotiation. If the card isn't detected, try switching between 357 and 600 first.

Phoenix readers sometimes need reverse polarity for card detection. If detect = cd doesn't work, try detect = !cd. This is a common gotcha that wastes hours if you don't know about it.

The group = 1 links this reader to user accounts that have group = 1 in oscam.user. Groups are how you control which clients can access which cards.

oscam.user: client accounts, group permissions, AU rights

[account]user = clientnamepwd = securepasswordgroup = 1au = mycard_viaccessbetatunnel = 0uniq = 0monlevel = 0

The au parameter enables EMM forwarding for this account, using the named reader. Only enable AU on clients you trust — EMMs can theoretically be used to write data to the card. Set au = 0 or omit it for standard clients.

uniq = 1 restricts this account to one simultaneous connection. Useful if you're sharing credentials with someone and don't want them connecting from multiple locations.

oscam.dvbapi: matching CAIDs to readers on the local box

[dvbapi]enabled = 1au = 1pmt_mode = 0request_mode = 0listen_port = 2000boxtype = dreambox

The DVBAPI section is for when OScam is running on the same box as the DVB hardware — like an Enigma2 receiver acting as both server and its own client. The boxtype value tells OScam which descrambler interface to use. For Vu+, use boxtype = vu. For generic Linux with CA devices, use boxtype = pc.

Web interface on port 8888 and what to monitor

The web UI at http://serverip:8888 is where you spend your debugging time. The important pages: Readers (shows card status, ECM/EMM counters, current CAID), Users (active connections, ECM count per user), and Logs (live stream of the oscam.log). The Services page shows which SIDs each reader is decoding.

ECM time shown here is your primary diagnostic metric. Green means under 500 ms. If you see consistent times above 1000 ms, something is wrong with the chain — either the card, the reader, or the network path.

Never expose port 8888 directly to the internet without HTTPS and strong credentials. The web interface has had vulnerabilities in older builds, and even a patched build leaks your user list and card details to anyone who can reach it. Use SSH tunneling or restrict access to a VPN.

Configuring a Client Receiver to Connect

Most people setting up satellite tv card sharing on the client side are running an Enigma2 image on a Dreambox, Vu+, or similar box. The process is similar regardless of image.

Enigma2 image choices: OpenATV, OpenPLi, VTi

OpenATV and OpenPLi are the most actively maintained as of 2026. OpenATV has broader hardware support and a cleaner feed for third-party plugins. OpenPLi is more conservative but very stable. VTi (Vu+ Team Image) is Vu+-specific and has good integration with their hardware. For a softcam setup, any of these work — the softcam panel integration is standard across all three.

Installing CCcam or OScam via feed or IPK package

On OpenATV, the softcam manager in the menu handles installation. You select a softcam (CCcam 2.3.x, OScam, or OScam-emu), and it pulls the IPK from the feed and installs it. Manual install is also an option — download the IPK and run opkg install /path/to/softcam.ipk over SSH. After install, the softcam appears in the Softcam Manager under Setup → System → Softcam Manager.

Editing CCcam.cfg: C-line syntax and reshare settings

The CCcam config lives at /var/etc/CCcam.cfg. A basic client-only config:

C: server.example.com 12000 myuser mypasswordRESHARE = 0RECV TIMEOUT = 5000SEND TIMEOUT = 5000

Setting RESHARE = 0 means your receiver won't reshare cards to other clients — just receives. RESHARE = 1 allows you to reshare at hop+1. Don't reshare unless you intend to run a server.

Restart the softcam after editing: /etc/init.d/softcam restart or use the Softcam Manager in the receiver's menu.

DVBAPI configuration on the client side

If you're running OScam as a client (connecting to a remote OScam server via Newcamd or CS378x) and also using DVBAPI locally for descrambling, the oscam.dvbapi config on the client needs to match your boxtype and point DVBAPI at the local descrambler on port 2000.

The client's oscam.server entry for a remote Newcamd connection looks like:

[reader]label = remote_serverprotocol = newcamddevice = server.example.com,15000key = 0102030405060708091011121314user = myuserpassword = mypasswordcaid = 0500group = 1

The 14-byte key is the Newcamd protocol key — both sides need to agree on this value. It's not a security token but a protocol initialization parameter.

Testing the connection: green/yellow/red light on EPG

After restarting the softcam on OpenATV or OpenPLi, go to a scrambled channel. The channel info pane (Info button) shows a small icon: green means the CW is arriving and decoding is working. Yellow means the card was found but decoding is slow or intermittent. Red means no CW. Black screen with red icon = connection problem or CAID mismatch.

For CCcam specifically, pressing the Blue button on many images opens the CCcam Info panel showing connected cards, hop count, and connected users. This is your quick verification step.

Troubleshooting Common Card Sharing Problems

Most problems fall into five categories. Here's how to diagnose each one systematically.

Channel says 'scrambled' or shows black screen

First check: is the softcam actually running? ps aux | grep oscam or ps aux | grep CCcam. If not running, start it.

If it's running, check the CAID. Open the OScam web UI (port 8888) and look at the Services tab. Find the channel's SID and check what CAID the transponder is using. Now check your oscam.dvbapi or CCcam config — does the CAID listed there match? A Viaccess channel (0500) won't decode with a Nagravision (1800) card no matter what.

Also check group assignment. If your reader is in group 1 and the user account doesn't have group = 1, OScam will show 'no matching reader' in the log.

Picture freezes every 10 seconds (CW timing)

This is the classic symptom of high ECM time. The CW rotates every 10 seconds. If the new CW arrives after the window closes, you get a 1-2 second freeze.

Go to the OScam web interface → Readers. Look at the "Last ECM" column. If it's consistently above 1000 ms, you have a timing problem. Above 1500 ms and you'll freeze on every rotation.

Possible causes: high network latency between client and server, overloaded server (too many clients on one card), or the card reader itself is slow (old Phoenix reader at wrong clock speed). Try ping server.example.com from the receiver — round-trip latency over 200 ms on a domestic connection is a problem for card sharing.

OScam log shows 'no matching reader' or 'CAID not found'

tail -f /tmp/.oscam/oscam.log | grep -E 'ecm|dyn|CAID'

Or check the log file at the path configured in oscam.conf. Look for lines containing 'no matching reader'. This means OScam received an ECM for a CAID that none of its readers serve. Either the card doesn't have entitlement for that CAS, or the CAID in the reader config doesn't match.

On Enigma2 boxes, the OScam log is often at /tmp/.oscam/oscam.log or wherever logfile points in oscam.conf. If you set logfile = stdout, use journalctl -u oscam -f for live output (assuming you have a systemd unit).

Connection drops after a few minutes

Two common causes: NAT timeout and keepalive settings.

ISP routers and carrier-grade NAT (CGNAT) boxes often drop idle TCP connections after 60–90 seconds of no data. Card sharing connections are bursty — if you're on a channel that changes CW infrequently, the TCP session goes quiet and the NAT entry expires. The next ECM request goes into the void.

Fix: enable keepalive in OScam. In oscam.conf add keepalive = 1. In CCcam.cfg, this is handled automatically if you're using a recent build. On the server side, make sure TCP keepalive is enabled at the OS level: net.ipv4.tcp_keepalive_time = 60 in sysctl.conf.

If you're behind CGNAT with no inbound ports (common on mobile or some ISPs), you can't accept inbound CCcam connections on port 12000. You have to operate purely as an outbound client. This means your receiver connects out to the server — which is the standard client mode anyway, so most people aren't affected unless they're trying to run a server behind CGNAT.

IPv6-only connections (some mobile networks) can't reach IPv4 card sharing servers unless there's NAT64 in place. Check with curl -6 ifconfig.me — if you only get an IPv6 address and no IPv4, you'll need a VPN or tunnel.

Reader status shows CARDOK but no decoding

CARDOK means OScam can communicate with the smartcard. But if the card doesn't have entitlement for the channel you're trying to watch, it'll return an error on every ECM. This is an expired subscription, a wrong subscription package, or a CAID assignment issue.

Check the Readers tab in the web UI. Look at the EMM and ECM counters. If ECM count is going up but decode count stays at zero, the card is receiving requests but returning failures. Check the log for 'CW error' or 'wrong CAID' messages.

Some mixed CAS environments have both Viaccess and Nagravision on the same transponder (Astra positions are full of these). Make sure your CAID list in the reader config includes all relevant CAIDs. Use a wildcard like caid = 0500,1800 if the card supports both.

What to Look For When Evaluating a Server (Generic Criteria Only)

There's a lot of noise around satellite tv card sharing server selection. Most of it is marketing. Here are the technical criteria that actually matter.

Uptime and ECM response time benchmarks

A server doing its job consistently will show ECM times under 500 ms measured from your location. Anything above 1000 ms on a regular basis means either the server is overloaded, the network path is poor, or you're dealing with reshares at hop 2 or 3.

Uptime matters too. A server at 99% uptime is down ~88 hours per year. At 99.9%, that's 8.8 hours. Ask whether a test period is available — any provider unwilling to offer at least a 24-hour test either knows the service is unreliable or doesn't stand behind it.

Local cards vs reshares: why hop matters

Hop 1 means the CW is generated by a physical smartcard in the server you're connecting to. Hop 2 means that server is itself connected to another server with the card. Every hop adds at minimum one network round-trip — 20–100 ms depending on geography and infrastructure.

Providers often market hop 1 but deliver hop 2 or higher. You can verify this in CCcam Info (Blue button) on your receiver — it shows the hop count for each connected card. You can also check in the OScam web UI under Services; the hop count is displayed per-CAID.

Latency between client and server location

Physical distance matters. A server in the same country as you might add 10–30 ms round-trip. A server across the Atlantic adds 80–120 ms. For a 500 ms ECM budget, that's a meaningful chunk. Check ping times before committing to a server.

If you're in mainland Europe watching European satellite positions, a server physically in Central Europe (Germany, Netherlands, Czech Republic) will generally outperform one routed through Asia or North America for obvious reasons.

Reasonable expectations for stability

No card sharing setup will be 100% stable forever. Broadcasters update their encryption keys, cards occasionally need re-pairing, servers need maintenance. What you're evaluating is how a provider handles these events — do they communicate? Do they resolve outages quickly? Is there a way to contact technical support, or just a web form?

Red flags: promises of "all channels from all satellites worldwide" (physically impossible with one card), prices that seem too low to cover server costs, no test period, no technical documentation, and no support channel beyond a chat widget.

Legal and Technical Risks to Understand

This section is neutral and factual. You should read it before setting anything up.

Copyright and conditional access laws by region

In the European Union, Directive 98/84/EC — the Conditional Access Directive — specifically targets devices and services that circumvent conditional access systems. Commercial trading in unauthorized card sharing access is clearly covered. Personal use in a single household with one valid subscription sits in a murkier position but isn't explicitly addressed uniformly across all member states.

In the United States, 47 U.S.C. § 605 covers unauthorized interception and publication of satellite communications. Criminal penalties apply to commercial-scale operations. Civil liability applies more broadly.

The general pattern: personal multi-room sharing of a card you legitimately own and paid for is a legal grey zone in many jurisdictions. Commercial resale of sharing access — charging others for decrypted CWs from a card you may or may not own — is clearly illegal nearly everywhere. Read the laws in your jurisdiction before doing anything.

Why the 'one card multiple rooms' boundary matters

Most legal analysis of card sharing hinges on whether you're sharing a subscription you've paid for within your own household versus distributing access commercially. The line between "I have three TVs in my house" and "I'm selling access to 50 people" is the difference between a grey area and a criminal offense in most EU countries.

ISP traffic patterns that can flag card sharing

Card sharing traffic is distinctive: persistent TCP connections to non-standard ports (12000, 15000, 10000), with regular small bursts of traffic every 10 seconds matching the CW rotation interval. Some ISPs do deep packet inspection and can identify this pattern. VPNs add another layer but also add latency, which can push ECM times over the freeze threshold.

Security risks of opening ports to the internet

If you run an OScam server, do not expose port 8888 to the internet without protection. The web interface shows your card details, user list, connected clients, and configuration — all visible to anyone who can reach it. Older OScam builds have had authentication bypasses. Even on patched builds, basic auth over plain HTTP is easily sniffed on public networks.

The correct approach: bind the web interface to localhost only (httpport = 127.0.0.1:8888 in oscam.conf) and use SSH port forwarding to access it when needed. For CCcam and OScam service ports (12000, 15000), restrict inbound access by IP in your firewall if you have a small, fixed set of client IPs.