Cardsharing Setup Guide: CCcam & OScam Config Walkthrough
If you've been hunting for a working cardsharing anleitung that actually shows you the file paths, the exact config syntax, and what to do when it breaks — this is it. Most guides either assume you already know half of it or were written for hardware that shipped in 2014. This one's written for 2026: Enigma2 boxes, Raspberry Pi builds, and OScam-SVN compiled from source.
This isn't a conceptual overview. You'll get real commands, real file locations, and annotated config blocks. By the end, you should have a working line decoded and know exactly which log entry to grep when it isn't.
What You Need Before You Start
Before touching a config file, sort out what kind of setup you're building. There are two fundamentally different scenarios, and they dictate everything that follows.
A local-card setup means you own a physical smartcard and a compatible USB or internal card reader. The card is physically in your machine or receiver. OScam or CCcam reads it directly — you are the server. A pure client setup means you have a C-line or N-line from a provider, and your box is connecting to a remote server that holds the card. Most users reading a cardsharing anleitung are in the second category.
Hardware: Enigma2 Receiver, Raspberry Pi, or Linux Server
Enigma2 boxes (Dreambox, VU+, Zgemma, etc.) run a Linux-based OS and have softcam plugin support built in. OScam installs cleanly from the feed. Raspberry Pi 3B/4 works well if you compile OScam from SVN — the ARM binary from random sites is usually outdated. A generic x86 Linux server is the easiest to manage long-term.
ARM vs MIPS matters. A VU+ Zero 4K uses ARM, a Dreambox 800 uses MIPS. The OScam binary you download must match your CPU architecture or it simply won't execute. If you're compiling from source with ./configure && make, this is handled automatically. If you're grabbing a precompiled binary from a feed, check the package name — oscam-emu_mipsel won't run on ARM.
Software: CCcam vs OScam — Which to Pick
CCcam is closed-source, development stopped years ago, and the protocol is essentially frozen. It's simple to configure — one file, C-lines, done. But it has no web interface, no active bug fixes, and limited protocol support.
OScam is open-source, actively maintained, and supports cccam, newcamd, mgcamd, and cs378x protocols simultaneously. It has a built-in web interface at port 8888, detailed logging, and a four-file config model that's more powerful once you understand it. For any new setup in 2026, use OScam. Only reach for CCcam if you're dealing with legacy hardware or a provider that only hands out CCcam C-lines and you need a quick client-only install.
A Working DVB Tuner and a Valid Line
Your DVB tuner needs to lock onto the satellite transponder before decryption even comes into play. Confirm signal first — use the signal finder in your receiver's menu. A scrambled channel showing as locked but black is a decryption problem. A channel that won't lock at all is a dish/cable problem, not a config problem. Don't debug OScam with a bad signal.
Network Requirements: Static LAN IP, Port Forwarding, Time Sync
Give your receiver or server a static LAN IP. Dynamic IPs from DHCP mean your port forwarding breaks when the lease renews. Set it in your router's DHCP reservation table using the device's MAC address — cleaner than setting it on the device itself.
NTP is non-negotiable. OScam uses timestamps for ECM validation, and if your system clock is more than a few seconds off the server's clock, you'll get instant disconnects or authentication failures that look like wrong passwords. On Raspbian: sudo timedatectl set-ntp true. On Enigma2: set the time server in the system settings and confirm it syncs on boot.
One edge case worth knowing: if your ISP uses CGNAT (common with mobile broadband and some cable providers), standard port forwarding won't work because you don't have a public IP. You'll need a VPN tunnel (WireGuard works well) or a VPS relay to bridge the connection. Double NAT — router behind a modem that's also doing NAT — has the same problem. Diagnose by checking your router's WAN IP against your public IP via a site like whatismyip. If they differ, you're behind CGNAT.
Installing CCcam and OScam
Install paths vary by platform, so I'll cover the main ones explicitly rather than hand-waving at "your config directory."
Installing OScam via Package Feed or SVN Build
On Enigma2, the fastest path is the package feed. In a terminal over SSH:
opkg updateopkg install oscamThis places the binary at /usr/bin/oscam and creates the config directory at /etc/oscam/. The init.d script at /etc/init.d/oscam handles start/stop.
On a Raspberry Pi or Debian-based server, compile from SVN. You'll need the dependencies first:
sudo apt install build-essential libssl-dev cmake subversionsvn co http://www.streamboard.tv/svn/oscam/trunk oscam-svncd oscam-svn./config.sh --enable MODULE_CCCAM --enable MODULE_NEWCAMD --enable READER_SMARTREADERmakeThe compiled binary lands in the Distribution/ subfolder. Copy it: sudo cp Distribution/oscam /usr/local/bin/oscam. Create your config directory at /etc/oscam/ manually: sudo mkdir /etc/oscam.
Run it in the background: oscam -b -c /etc/oscam. The -b flag daemonizes it; -c points to your config directory.
Placing the CCcam Binary and Setting Permissions
On Enigma2, CCcam installs from the package feed similarly to OScam. The binary goes to /usr/bin/CCcam. If you're copying a binary manually:
cp CCcam /usr/bin/CCcamchmod 755 /usr/bin/CCcamWithout the execute bit set, it just silently does nothing. chmod 755 is your first debugging step if CCcam won't start.
Where Config Files Live
CCcam reads from /var/keys/CCcam.cfg or /etc/tuxbox/config/CCcam.cfg depending on the image. Some images check both; some check only one. If CCcam starts but ignores your config, you've put the file in the wrong location. Check the startup script to see which path it passes:
cat /etc/init.d/softcam | grep CCcamOScam's config directory is typically /etc/oscam/ on fresh installs or /var/etc/oscam/ on older Enigma2 images. The -c flag you use at startup determines this — always use an absolute path.
Starting and Stopping the Emu
On Enigma2, the softcam panel plugin handles this. On a headless Linux server, create a systemd unit file at /etc/systemd/system/oscam.service:
[Unit]Description=OSCam[Service]ExecStart=/usr/local/bin/oscam -b -c /etc/oscamRestart=on-failure[Install]WantedBy=multi-user.targetThen: sudo systemctl enable oscam && sudo systemctl start oscam. Logs go where logfile= points in your oscam.conf — set it to /var/log/oscam.log and make sure the directory exists.
Editing the Config Files Correctly
This is where most cardsharing anleitung guides fall apart — they show a config file but never explain what each field actually does. I'll go through it field by field.
CCcam.cfg: C-Line Syntax
A CCcam C-line has this exact format:
C: my.server.tld 12000 myusername mypassword no { 0:0:2 }Breaking it down:
C:— declares this is a client line connecting to a CCcam servermy.server.tld— hostname or IP of the server12000— TCP port the server is listening onmyusername— case-sensitive username (wrong case = auth failure)mypassword— case-sensitive passwordno— whether to share received cards back upstream (almost alwaysnofor client setups){ 0:0:2 }— optional: CAID filter, hop limit, reshare level
The fields after the password are optional but can help restrict what the line shares or requests. Whitespace matters — use single spaces between fields. Tabs will break parsing in some CCcam versions.
Server Side: F-Lines and N-Lines
If you're running a CCcam server (local card setup), you declare allowed clients with F-lines:
F: clientusername clientpassword 1 0 0 0 { 0:0:2 }N-lines are for Newcamd protocol connections. They look different — they include a DES key:
N: my.server.tld 15000 user pass 01 02 03 04 05 06 07 08 09 10 11 12 13 14The 14-byte hex key must match on both client and server. Most people just leave the default key — that's fine for a private setup, not for anything security-sensitive.
OScam Four-File Model: oscam.conf, oscam.server, oscam.user, oscam.services
OScam splits its configuration across four files. Understanding this is the entire key to making OScam work. Every guide that doesn't explain this leaves users confused about why changes in one file don't affect anything.
- oscam.conf — global settings: logging, the web interface, which protocol modules to load ([cccam], [newcamd], [dvbapi])
- oscam.server — [reader] blocks: each upstream source (a remote C-line, a local card reader) gets one block
- oscam.user — [account] blocks: each client connecting to your OScam instance gets one block
- oscam.services — optional: CAID/provider/SID filters to control which services each reader or account can access
OScam Reader Block and Account Block Fields
Here's a reader block connecting to a remote CCcam server:
[reader]label = my_clineprotocol = cccamdevice = my.server.tld,12000user = myusernamepassword = mypasswordgroup = 1cccversion = 2.3.0ccckeepalive = 1And a matching account block for a local DVBAPI client:
[account]user = localboxpwd = localpasswordgroup = 1au = 1uniq = 0The group field is what links them. When a local client (via DVBAPI) asks for a key, OScam routes the ECM request to readers in the same group. If your account is in group=1 and your reader is in group=2, they'll never talk to each other and you'll see "no matching reader" in the log every time.
For a pure client setup (no local card), set au = 0 in the account block. EMM updates are only needed when you have a physical card that requires subscription updates — they're irrelevant for remote lines.
DVBAPI Setup: oscam.dvbapi and the [dvbapi] Section
The [dvbapi] section in oscam.conf connects OScam to the DVB demux on your receiver:
[dvbapi]enabled = 1user = localboxboxtype = dreamboxau = 1pmt_mode = 0The user field here must exactly match an account in oscam.user. The boxtype depends on your hardware: dreambox, vuplus, dbox2, etc. Wrong boxtype usually results in decryption that starts then stops, or works on some channels but not others.
On Enigma2, OScam communicates with the OS via a socket at /tmp/camd.socket (for Camd35/cs357x) or directly via the DVB device nodes. The pmt_mode setting controls how channel changes are detected — 0 works for most setups.
The global oscam.conf section also needs:
[global]logfile = /var/log/oscam.logmaxlogsize = 200nice = -1[webif]httpport = 8888httpuser = adminhttppwd = yourpassword[cccam]port = 12001Set a strong httppwd. Without TLS (which most LAN setups skip), the password goes in plaintext — fine on a private LAN, not fine if the interface is exposed publicly. If you lock yourself out by setting httpuser/httppwd and forgetting the credentials, edit the config file directly and restart OScam. There's no "forgot password" option.
Ports, Firewall, and Connecting Client to Server
Getting the port configuration right is one of the most common stumbling points in any cardsharing anleitung. The numbers need to match across your router, your server config, and your client config — all three.
Default Ports
| Protocol | Default Port | Config Location |
|---|---|---|
| CCcam | 12000 | CCcam.cfg C-line / F-line port field |
| Newcamd | 15000 | oscam.conf [newcamd] port= |
| CS378x (cs357x) | 15001 | oscam.conf [cs357x] port= |
| OScam Web Interface | 8888 | oscam.conf [webif] httpport= |
These are defaults, not requirements. You can run CCcam on port 5500 if you want — just make sure the C-line and the server's listening port match exactly. Mismatched ports mean the TCP connection never establishes, which looks identical in the logs to a firewall block.
Port Forwarding on the Router
If you're running a server at home and clients are connecting from outside your LAN, you need to forward the server's listening port on your router to the server's static LAN IP. Most router UIs have this under "Port Forwarding" or "Virtual Server." Protocol is TCP. External port = internal port (unless you're remapping).
If you're behind CGNAT — your router's WAN IP isn't your public IP — port forwarding won't help. The solution most people land on is a cheap VPS as a relay: WireGuard tunnel from your home server to the VPS, then the port is exposed on the VPS's public IP. It adds a few milliseconds of latency but it works.
Testing the Connection: OScam Web Interface and CCcam Info Page
Before blaming OScam config, test whether the TCP port is actually reachable:
nc -zv my.server.tld 12000Or with telnet: telnet my.server.tld 12000. If you get "Connection refused" or timeout, the port isn't open — fix the firewall before touching configs. If you get a connection and then it drops, the server is listening but your credentials or protocol are wrong.
The OScam web interface at http://receiver-ip:8888 shows reader status in real time. Navigate to "Readers" and look for the status column. CONNECTED means the line is up and active. CONNECT_ERROR means the TCP connection failed. CARDINFO ERROR means it connected but authentication or card polling failed.
Reading the Share List: Hops and Entitlements
In the web interface, click a reader to see card info. "Card found, 0 hops" means the server has the physical card directly. "1 hop" means there's one server between you and the card. Each hop adds a few milliseconds to ECM time.
High hop counts — 3 or more — usually cause noticeable freezes on fast-changing channels. Most providers sit at 1 hop. If a provider tells you their hops but you see 3 in OScam, something's wrong with their infrastructure or they're re-sharing.
Troubleshooting: Freezes, ECM Errors, and No Picture
Most problems have specific symptoms. If you know what to look for in the log, you can diagnose in minutes instead of hours of random config changes.
ECM Timeout and High ECM Time
Freeze every 10–30 seconds? ECM time is probably too high. The control word that decrypts the stream needs to be renewed periodically — if the new key arrives too late, you see a freeze. Check ECM time in the OScam web interface under Readers. Anything under 500ms is fine. Over 1000ms is likely to cause visible interruptions.
Fixes: use a geographically closer server, restrict CAID/provider in oscam.services to avoid OScam trying multiple readers before picking the right one, lower uphops in the reader block to reject cards more than N hops away:
[reader]...uphops = 1Green or Black Screen: Wrong CAID or No Entitlement
Green screen (or black screen, depending on the receiver) with no freeze — the decryption never starts. Either the CAID/provider ID for that channel doesn't match what your line carries, or your oscam.services is filtering it out incorrectly.
Find the channel's CAID from the transponder info in your receiver's menu. Cross-reference it with what OScam shows in Reader > Entitlements. If it's not listed, your line doesn't carry that CAID. If it's listed but still not working, check oscam.services for any explicit block on that SID or CAID:provid combination.
Connection Drops and Reconnect Loops
Reconnect loop — OScam connects, disconnects, connects again every few seconds — usually points to one of three things: wrong password, a sharelimit on the server side (too many simultaneous connections), or time skew. Check the exact error:
grep 'ecm\|error\|reject' /var/log/oscam.log | tail -50"rejected" followed by a username means the server knows about the user but is refusing the connection — sharelimit or account expired. "invalid user" means wrong username. An immediate disconnect without any auth exchange is almost always time skew.
Wrong System Time / NTP Causing Instant Disconnects
This is the one thing almost no cardsharing anleitung mentions, but it bites people constantly. If your receiver's clock is off by more than ~30 seconds from the server's clock, the TLS handshake or the cccam protocol timestamp check fails and you get an instant disconnect that looks exactly like a wrong password.
Check your time: date on the receiver, then compare to an NTP-synchronized machine or an online time service. Fix it:
# On Enigma2:ntpdate pool.ntp.org# On Raspberry Pi / Debian:sudo systemctl restart systemd-timesyncdtimedatectl statusReading oscam.log to Diagnose: No Matching Reader, Group Mismatch
"no matching reader" in the log means an ECM request came in but no reader in the matched group could handle it. Almost always a group mismatch. Check that the account's group= and the reader's group= share at least one number.
OScam's log is verbose once you know the format. A successful ECM decode looks like:
2026/06/12 14:33:12 c (dvbapi) [user=localbox] ECM caid 0500 from dvbapi: found (16 ms) by my_clineFailed: not found (500 ms) by any reader or timeout by reader my_cline. The timing in parentheses is your ECM time — watch that number.
How to Choose a Provider (Without Getting Burned)
Choosing a line is where people make expensive mistakes. The technical setup is the easy part — picking a reliable source is where you need to be picky.
What a Good Line Looks Like
A solid provider should be willing to offer a test line — typically 24–48 hours — before you pay. During that test, check ECM time in OScam: consistent sub-300ms is excellent, sub-500ms is acceptable, anything over 800ms will be annoying. Test during peak hours (evenings, weekend afternoons), not at 3am when load is minimal.
Ask specifically which CAIDs and provider IDs they carry. A good provider knows exactly which packages they have and can give you the CAID:provid combination so you can verify it matches what you see in OScam. Vague answers like "we carry everything" are a red flag.
Red Flags: Oversold Servers and No Test Line
Any provider that refuses a test line is hiding something — usually an oversold server. Overselling means they've given out more C-lines than the server can simultaneously handle, so performance degrades during peak hours. The test lets you catch this before paying.
Constant freezes that appear at 8pm but not at 10am? Oversold. If support blames your receiver, your config, or your internet connection without looking at server-side ECM stats, walk away.
Local Card vs Remote Line: Control and Reliability
A local smart card with a USB reader gives you full control — you're not dependent on a third party's uptime. The card needs periodic EMM updates to stay valid, which OScam handles automatically with au = 1 in the reader block. But you need to actually own and maintain a valid subscription.
Remote lines are convenient but fragile by nature. The provider controls uptime, and if they go down at midnight you're stuck. Local cards don't have that problem — but they do have the problem that if the provider changes their encryption parameters and your card doesn't get the update in time, you lose reception until EMM syncs.
Legal Note and Personal-Use Responsibility
What you're legally entitled to decrypt depends entirely on your jurisdiction and what subscriptions you hold. The setup described in this guide — OScam, CCcam, DVB decryption — can be used entirely legally with cards you own and subscriptions you pay for. Using it to decrypt content you don't have entitlements for is a different matter, and the legal situation varies significantly by country. Know your local law. That's your responsibility, not mine.
Frequently Asked Questions
Should I use CCcam or OScam for my setup?
OScam. It's open-source, actively developed, supports cccam, newcamd, mgcamd, and cs378x protocols all at once, and has a web interface for real-time monitoring. CCcam is simpler to configure for a pure client setup, but development is dead and it gives you no visibility into what's happening. The only reason to use CCcam today is compatibility with legacy hardware or a provider that exclusively issues CCcam C-lines and you need something running in ten minutes.
Where is the CCcam.cfg or oscam.conf file located?
On Enigma2, CCcam.cfg is typically at /var/keys/CCcam.cfg or /etc/tuxbox/config/CCcam.cfg — check your image's startup script to confirm which path it reads. OScam config files (oscam.conf, oscam.server, oscam.user, oscam.services) live in /etc/oscam/ on most builds, or /var/etc/oscam/ on older Enigma2 images. The definitive answer is whatever -c path you pass to the oscam binary at startup.
What does a C-line look like and what do the fields mean?
Format: C: hostname port username password. For example: C: my.server.tld 12000 myuser mypass. Hostname and port point to the server's listening address. Username and password are case-sensitive — wrong case looks identical to wrong credentials in the log. Optional fields in braces control sharing and hop limits. All fields are space-separated; tabs cause silent parse failures in some CCcam builds.
Why does my picture freeze every few seconds?
Nine times out of ten: high ECM time. Check it in the OScam web interface under Readers. Over ~800ms and you'll see periodic freezes as control word renewals come in late. Fix it by using a lower-latency line, setting uphops = 1 in your reader block to reject high-hop shares, or adding CAID/provider filtering in oscam.services so OScam doesn't waste time querying readers that can't help. Also verify NTP — a drifting clock can cause ECM authentication failures that look like slow decoding.
Which ports do I need to open?
CCcam default is TCP 12000. Newcamd is TCP 15000. CS378x is typically TCP 15001. OScam's web interface runs on TCP 8888 (LAN only — don't expose this externally without authentication and ideally a VPN). Forward whichever port your server is listening on through your router to the server's LAN IP. Client config must specify the same port. Mismatch = connection refused, which looks the same as a firewall block.
The OScam web interface shows CONNECT_ERROR — what now?
Start with a basic TCP test: nc -zv hostname port from the receiver. If that fails, the port isn't reachable — check firewall and port forwarding before touching configs. If TCP connects but OScam still shows CONNECT_ERROR, check username/password (both case-sensitive), verify the [account] group= matches the [reader] group=, and confirm system time is synced via NTP. A clock skew of more than ~30 seconds causes immediate disconnects that are indistinguishable from auth failures in the log.