Satellite TV Without Subscription: CCcam/OScam Setup 2026

If you've spent any time in Enigma2 forums, you've seen people talking about running satellite TV without subscription through card sharing setups instead of paying a broadcaster every month. The tech behind this isn't magic — it's a fairly simple network trick built on top of how DVB conditional access already works. This guide walks through the actual protocol mechanics, the config files you'll touch on a real receiver, and the troubleshooting steps that separate a smooth setup from a black screen at 8pm on match night.

I'm not going to point you toward any specific card source. This is a technical breakdown of how CCcam and OScam function, how to configure a client, and how to read your logs when something breaks. What you do with a working config, and where you get a line from, is on you — and the legality of that varies a lot depending on where you live.

How Card Sharing Delivers Satellite TV Without a Per-Box Subscription

Every encrypted satellite channel sends out ECMs — Entitlement Control Messages — every few seconds. Your receiver's CAM (conditional access module) grabs the ECM and hands it to a smartcard. If the card is entitled to that channel, it decrypts the ECM and spits back a Control Word (CW), a short key that the receiver uses to decrypt the actual video and audio stream. That's it. That's the entire trick that makes pay-TV pay-TV.

Card sharing takes that CW handoff and moves it over IP. Instead of a physical smartcard sitting in your own receiver, the ECM gets forwarded across a network to a machine that does have the card, and the CW comes back the same way. Your box never sees the physical card — it just gets fed the CW it needs, fast enough that you never notice the round trip. This is the whole mechanism behind satellite TV without subscription setups: you're not stripping encryption, you're just relocating where the decryption happens.

What the smartcard actually does (ECM and control words)

The card itself does almost nothing computationally heavy. It checks the ECM against its entitlement data (which packages, which caid/provid combos it's allowed to decode) and if it matches, returns the CW. A CW is usually valid for around 10 seconds before the broadcaster rotates it, which is why timing matters so much in a shared setup — more on that in the troubleshooting section.

Client vs server roles in a sharing setup

In any sharing arrangement there's a server (holds the card, answers ECM requests) and a client (has no card, forwards ECMs out and waits for a CW). Your receiver running OScam or CCcam in client mode is just a piece of software that intercepts what would normally go to a local CAM and instead ships it to a remote host over TCP.

Why one card can serve multiple receivers over a network

Because ECM/CW traffic is tiny — a few hundred bytes per request — a single card sitting in a dongle or a card reader on one machine can theoretically answer requests from several receivers on a LAN or over the internet. This is the entire economic logic behind card sharing: one physical subscription, decrypted once, redistributed as key data rather than as video.

CCcam vs OScam vs MGcamd at a protocol level

CCcam is a closed-source softcam with its own proprietary protocol (also called CCcam) running over TCP, historically on ports in the 12000-17000 range depending on config. It's simple to set up but you're stuck with whatever the binary supports — no source, no real debugging beyond log output.

OScam is open source and, in my experience, the more serious tool for anyone actually troubleshooting a setup. It speaks cccam, newcamd, camd35, and radegast protocols, meaning a single OScam instance can connect to sources running any of these. It also ships with a proper web interface for live reader status, which CCcam doesn't have natively.

MGcamd is a newcamd-only client, lighter weight, common on older MIPS-based Enigma2 boxes where OScam's overhead was a problem. On modern receivers (ARM-based Vu+, Zgemma, Dreambox two 2 units) OScam is generally the better default since hardware isn't the bottleneck anymore.

Setting Up an OScam Client: Config Files, Paths and Ports

OScam configuration lives in plain text files, which is honestly the best thing about it — no binary blobs to guess at. On most Enigma2 images you'll find them under /etc/tuxbox/config/oscam/, though some older builds or box-specific images (older Dreambox flashes especially) put them in /usr/keys instead. If you can't find the directory, check both before assuming the config doesn't exist.

Directory layout: /etc/tuxbox/config/oscam/ and /var/keys

The core files are oscam.conf, oscam.server, oscam.user, oscam.services, and oscam.dvbapi. Some images symlink these into /var/keys for convenience, so editing one edits the other — check with ls -la before you assume you're editing the live file.

oscam.conf global and monitor settings

This file controls global behavior — logging verbosity, the web interface port, and monitor settings for telnet access if you use that. A typical global block looks like:

[global]logfile = /tmp/oscam.logclienttimeout = 5000fallbacktimeout = 4000resolvegethostbyname = 1[webif]httpport = 8888httpuser = adminhttppwd = changeme

Note the default httpport of 8888 — some images ship with 83 or 8080 instead, so check your image's default before assuming 8888 is right. Whatever it is, you reach it at http://receiver-ip:8888 from a browser on the same network.

oscam.server: defining a CCcam or newcamd reader

Each source you connect to gets a [reader] block in oscam.server. For a CCcam-protocol source it looks roughly like this (values below are placeholders, not a real line):

[reader]label = source1protocol = cccamdevice = 203.0.113.10,17000user = myusernamepassword = mypasswordgroup = 1cccversion = 2.3.2inactivitytimeout = 30

The device field takes host,port — port has to match exactly what the source is running, and if it's wrong you'll see a connection refused or timeout in the log within seconds. The group value ties this reader to specific user accounts in oscam.user, which is how you control which local clients can use which reader.

oscam.user: local client accounts and group mapping

This is where you define who's allowed to pull CWs from your OScam instance locally (or from other boxes on your LAN, if you're bridging multiple receivers off one server). A basic account block:

[account]user = localclientpwd = localpassgroup = 1au = 1uniq = 1

The group = 1 here has to match the reader's group in oscam.server or the account won't be able to use that reader at all — this trips up more first-time setups than almost anything else.

Restarting and checking the web interface on port 8888

After editing any of these files, restart OScam — usually /etc/init.d/softcam.oscam restart or through the receiver's plugin menu under Softcam setup. Then hit the WebIf at http://receiver-ip:8888 and check the Readers tab. A working reader shows a green "connected" status; anything else and you're straight into the troubleshooting section below.

Configuring a CCcam Client (CCcam.cfg) and DVBAPI

If you're running CCcam directly rather than through OScam, everything lives in one file: CCcam.cfg, typically found in /etc, /var/etc, or /usr/keys depending on the image (OpenATV and OpenPLi put it in slightly different spots, so check both if it's missing).

CCcam.cfg C-line syntax explained field by field

A C-line is what defines an outbound connection to a card source:

C: 203.0.113.10 17000 myusername mypassword

Four fields, in order: host, port, username, password. That's the whole syntax — no group numbers, no protocol flags, unlike OScam's more granular reader blocks. Some CCcam builds support an optional trailing flag for forwarding behavior (whether this connection's card gets re-shared to your own F-line clients), but the base four fields are mandatory.

F-line for sharing back to your own clients

If you want other receivers to pull cards from your box, you add an F-line:

F: myaccountname myaccountpass 0 0 0

The trailing zeros control hop limits and forwarding restrictions — leaving them at 0 generally means no extra restriction beyond CCcam's defaults. This is server-side config though; most people running a single client box never need an F-line at all.

Enabling dvbapi so OScam feeds the box tuner

If you're using OScam instead of CCcam directly, the piece that actually talks to the receiver's tuner is oscam.dvbapi. It needs to be enabled and pointed at the right device:

[dvbapi]enabled = 1pmt_mode = 4boxtype = pc

Set boxtype to match your hardware family — many Enigma2 images auto-detect this correctly, but if channels don't decrypt at all despite a connected reader, forcing the boxtype explicitly (dreambox, duckbox, or pc for generic Linux) is worth trying.

Priority, ignore and services files

oscam.dvbapi also supports P: (priority) and I: (ignore) lines that control which reader answers which channel when you have more than one source configured:

P: 0100:000000 0963 01 & 03200000 # priority reader1I: 0100:000000 0963 03 # ignore reader on this caid

These matter once you're juggling multiple sources — without them OScam picks readers by its own internal logic, which isn't always what you want if one source is faster than another for the same channel.

One thing worth flagging clearly: don't run CCcam and OScam simultaneously if both are configured to control dvbapi. They'll fight over the tuner interface and you'll get a black screen instead of a picture. Pick one to own dvbapi — usually OScam, bridging in a CCcam-protocol reader if you need to connect to a CCcam-style source — and disable the other's softcam plugin entirely.

Troubleshooting: Freezing, No CW Found, and High ECM Times

This is the section most guides skip, and it's the one that actually matters once you've got something running. A working config today doesn't mean a working stream tomorrow — networks drift, sources get overloaded, and clocks slip.

Reading the OScam log and status page

Tail the log with tail -f /tmp/oscam.log and watch for lines showing reader status and ECM response time in milliseconds. A healthy line looks something like:

reader1 (11111111&M#S) ECM found (0 ms rsp) - CW 12345678...

The number in parentheses is your ECM time. Under roughly 300-500ms is smooth viewing. Once you're pushing past 900ms consistently, expect visible freezing on scene changes and fast-motion content — sports especially.

'CW not found' vs 'reader not connected'

These are two completely different problems and beginners mix them up constantly. "Reader not connected" means OScam can't even reach the source — network issue, wrong port, or the source itself is down. "CW not found" means the connection is fine but the card doesn't have the entitlement for that specific channel — wrong caid/provid, package not included, or the source dropped that channel from its lineup.

Diagnosing high ECM time and channel freezing

If your reader shows connected but ECM times are consistently high, the problem is almost always network path, not your config. Run a basic ping and traceroute to the source IP — if you're seeing 150ms+ latency or packet loss, that's your freezing explained right there. Reshared lines (a card sitting several hops away from the original source) tend to run higher ECM times than a source with a local, original card, simply because every hop adds latency.

Firewall, NAT and port-forwarding checks

If you're the one running the server side and outside clients can't connect, check that the reader/server port is actually forwarded on your router and not blocked by a software firewall on the host machine. A common gotcha: double-NAT setups where a modem/router combo assigns you a private IP, and your own router sits behind that — port forwarding on your router alone won't fix it because the outer device is also NATing you.

Worse is CGNAT (Carrier-Grade NAT), which a lot of ISPs use now for IPv4 conservation. If your ISP has you behind CGNAT, you don't have a public IP at all, and no amount of port forwarding on your own equipment will let inbound connections reach you. You'd need a VPN with a public endpoint or a business-tier connection to work around it. This only matters if you're hosting a server yourself — pure clients connecting outbound aren't affected by CGNAT at all.

Network jitter and MTU issues

If your sharing traffic runs over a VPN tunnel, watch for MTU/fragmentation problems. Standard Ethernet MTU is 1500 bytes, but VPN overhead (OpenVPN, WireGuard) eats into that, and if packets get fragmented or dropped as a result, you'll see intermittent ECM timeouts that look random but aren't. Lowering the tunnel's MTU slightly (trying 1400 or 1350) often clears this up.

Also check your receiver's system clock. If NTP isn't syncing — common after a power cut or a reboot on a box with a dead RTC battery — the clock can drift enough to break authentication handshakes with some protocols, or make ECM timing look wrong in the log even when the network is fine. Enable NTP sync in the Enigma2 network settings and confirm the date/time actually matches reality after a reboot.

How to Evaluate a Card-Sharing Source (Generic Criteria Only)

I won't name providers here — partly because I'd rather this page stay useful in six months instead of turning into a dead list of dead links, and partly because the criteria matter more than any specific name anyway. Here's what to actually check before committing to a source for satellite TV without subscription.

Uptime and reliability signals to test yourself

Don't take anyone's word for uptime. Watch your own OScam log over a few days across different times — early morning, prime time, weekend peak. A source that's rock solid at 3am but chokes at 9pm on a Saturday is telling you something about how oversold it is.

Local card vs reshared line — how to tell

Sources with a card local to their server tend to show consistently low, stable ECM times. Reshared lines (a chain of servers passing the same card's access down through multiple hops) usually show higher and more variable ECM times, and are more prone to dropping out entirely if any hop in the chain has an issue. You can't always tell which you're getting up front, but your own logged ECM times over time will tell you.

ECM response time as a quality metric

This is the single most honest metric you have, and it's one you generate yourself rather than trusting a claim. Log your average ECM time across a range of channels and times of day. If it's consistently under 400ms, that's a good source. If it's regularly bouncing above 800-900ms, expect freezing regardless of what anyone tells you about their setup.

Legal and account-security considerations

Be skeptical of anything asking for admin access to your router or your receiver's root credentials — that's a red flag regardless of how the setup is framed. And be clear-eyed about the legal side: accessing encrypted pay-TV broadcasts without authorization from the rights holder is illegal in a lot of jurisdictions, full stop. This page explains how the technology works from a networking and protocol standpoint. What you do with that information, and whether it's legal where you live, is entirely your call and your responsibility.