Cardsharing server: setting up CCcam and OScam from scratch

If you already know what ECM is and why a smart reader is needed, this article is for you. Setting up a cardsharing server by yourself is quite a feasible task, even if you have only connected to others before. Here we will cover everything from the structure of configs to diagnosing freezes, without fluff and without advertising other services.

What is a cardsharing server and how does it work

The satellite signal is encrypted. The receiver receives what is called an ECM packet (Entitlement Control Message) — this is a request for decryption that needs to be sent to the smart card. The card returns a control word (CW, Control Word), and with it, the decoder opens the picture. Without CW — a black screen.

The cardsharing server is in the middle: it receives ECM from several clients, sends it to the physical card in its reader, receives CW, and distributes it back. The client doesn't even know that the card is not with them.

Principle of operation: ECM, CW, and DCW

ECM is an encrypted request specific to the provider. CW changes every ~10 seconds (crypto period). DCW (Decrypted Control Word) is the already decrypted control word that the receiver uses directly for decoding the stream.

The delay between the request and receiving CW is the ECM time. If it is above 400–500 ms, the picture starts to freeze with each change of CW. Above 700 ms — stable viewing becomes impossible.

The role of the server and client in the scheme

The server is a machine with a physical smart reader and installed software (CCcam or OScam). The client is a receiver without a card that connects to the server over the network and sends it ECM requests. The server responds with CW, and the client decodes the signal.

One server theoretically serves several clients simultaneously — but with limitations, because one ECM request can only be processed by the card at a time.

CCcam vs OScam: key differences

CCcam is a closed binary, operates on port 12000/TCP by default. Configuration is done through a single file CCcam.cfg. Simple, predictable, but inflexible. Debugging is done via telnet on port 16001.

OScam is open source, built for ARM, x86, MIPS. Supports multiple protocols simultaneously: newcamd (port 15000+), cccam, camd35 (UDP, port 34000), gbox. Web interface on port 8888 with the status of each reader in real time. Configs are divided by functions: oscam.conf, oscam.server, oscam.user, oscam.srvid. This is more complex at first acquaintance, but gives full control.

I would recommend OScam for any serious cardsharing server — if only for the sake of normal logs and a web interface for diagnostics.

Installation and basic setup of OScam server

OScam is not included in the standard repositories of most distributions. Either build from source or take a ready-made build for your platform.

Building OScam from source and installing ready-made builds

To build, you need cmake, gcc, and libssl-dev. On Debian/Ubuntu:

apt install build-essential cmake libssl-dev libpcsclite-dev

For ARM receivers (Enigma2, VU+, Dreambox), it is more convenient to take ready-made ipk or tar.gz builds — building for the required toolchain requires a separate environment. On OpenPLi and OpenATV, there is a plugin through Feeds directly from the menu.

Structure of the directory /etc/tuxbox/config or /var/etc

The paths of the configs depend on the firmware and platform. On Enigma2 receivers, it is usually/etc/tuxbox/config/. On a clean Linux server —/usr/local/etc/ or/etc/oscam/. On routers with OpenWRT and Entware, it is more common to find/opt/etc/oscam/.

When starting, OScam looks for configs where specified by the flag-c. You can explicitly set the path like this:

oscam -b -r 2 -c /etc/tuxbox/config/

The flag-b — background mode,-r 2 — logging level (0–4, where 4 is maximum).

File oscam.conf: sections [global], [cs357x], [cccam], [webif]

Minimum workingoscam.conf:

[global]

Section[webif] — this is your main monitoring tool. Without it, diagnosing problems is twice as difficult.httpallowed restricts access to the web interface by IP — do not neglect this.

In the section[newcamd] a line like15000@0500:032830 means: port 15000, CAID 0500, provider 032830. If there are multiple providers — multiple port lines.

File oscam.server: connecting the card reader

Here, the physical reader is described — the internal slot of the receiver or an external USB reader:

[reader]

protocol = internal — for the built-in slot of Enigma2. For USB readers like Phoenix —protocol = mouse, device points to/dev/ttyUSB0. For SmartReader+ —protocol = smartreader.

mhz andcardmhz — the clock frequency of the reader and card in hundredths of MHz. 600 = 6.00 MHz — standard for most cards. If the card does not initialize, try 357 (3.57 MHz) or 368.

If you have multiple readers with different CAID and providers, priority is set throughcaid andprovid. OScam selects the reader by matching. In case of conflict — use thepriority parameter in each[reader].

File oscam.user: creating client accounts

[account]

au = 1 enables EMM auto-update for this user.uniq = 1 — only one connection with this login at the same time. You can also specifyallowedip = 192.168.1.50 to limit by IP — very useful for security.

Setting up the CCcam server: CCcam.cfg

CCcam lives in one file. On most Enigma2 receivers, this is/var/etc/CCcam.cfg. Sometimes you may find/etc/CCcam.cfg — it depends on the firmware.

Lines F: for clients and C: for peers

LineF: — this is the client account to which the server gives CW:

F: username password 1 0 { 0:0:2 }

Format: login, password, hops (1), share distance (0), then CAID restrictions in curly braces.0:0:2 — allow all CAID with a distance of up to 2.

LineC: — connection to the upstream server (peer):

C: hostname.example.com 12000 myuser mypass no

The last parameter — use of AES encryption:no oryes. Most servers operate without it.

Parameters hops, distance and share limits

Hops — the number of "jumps" from the original card to your client. Hop 1 = card directly at your server. Hop 2 = through one intermediate server. Each additional hop adds latency.

Hops > 2 — this is already a problem. ECM time increases, stability decreases. Practice shows: at hop=3 and ping 50+ ms, freezes become regular. You can limit the maximum hops in CCcam.cfg with the parameterSHARE LIMIT IN HOPS: in the header of the file.

distance in the lineF: — how far from your card your client can get a share. 0 = only your card. 1 = your card and the cards of your direct peers.

CCcam.providers files and priorities

CCcam.providers is an optional file describing CAID and providers. It allows you to set human-readable names and filter packages. It is located next to CCcam.cfg. Syntax:CAID:provid:name, for example0500:032830:Cyfra+.

If multipleC: lines lead to servers with the same CAID, CCcam selects in order from the file and the minimum response time. This cannot be explicitly controlled in CCcam — here OScam wins due to the parameterweight in oscam.server.

Starting the daemon and logging

Starting CCcam on Enigma2 is usually done through init.d:/etc/init.d/softcam start. Restarting the daemon directly:killall -9 CCcam&& CCcam&.

Logs are available via telnet on port 16001:

telnet localhost 16001

Commands:l — show log,r — reader info,s — server stats. This is the only way for real diagnostics in CCcam — there is no web interface, which is its main drawback.

Opening ports, forwarding, and network security

Even a perfectly configured card sharing server will not work for external clients if the network is not set up. This is often the reason for "not connecting".

Standard ports: 12000 (CCcam), 8888 (webif), newcamd

Standard ports by protocols:

• CCcam protocol:12000/TCP
• OScam web interface:8888/TCP
• Newcamd:15000–15099/TCP (usually 15000 or 15001)
• Camd35:34000/UDP
• CCcam telnet:16001/TCP

All these ports need to be opened both on the server's firewall and forwarded on the router. Don't forget: ufw or iptables on Linux can quietly block incoming connections even with correct NAT on the router.

Port forwarding on the router (NAT/port forwarding)

The scheme is standard: in the router settings, add a NAT rule — external port 12000 TCP → internal server IP (for example, 192.168.1.100), port 12000. Repeat for each used port.

An important point: the server's IP inside the network must be static. Either set it manually in the network interface settings or assign a static lease in the router's DHCP by MAC address.

A separate story is CGNAT. Some providers issue a "gray" IP behind several levels of NAT, and port forwarding simply does not work physically. It's easy to check: if the external IP in the router settings matches what is shown, for example,curl ifconfig.me on the server — you are behind CGNAT. The solution: buy a public IP from the provider, set up a VPN tunnel (WireGuard or OpenVPN) to a VPS with a public IP, or use a reverse tunnel.

Static IP, DDNS, and dynamic address

If the provider issues a dynamic public IP, DDNS is needed. The idea is simple: a DynDNS client on the router or server updates the record every few minutes in the form ofmyserver.duckdns.org, and clients connect by name, not by IP.

DuckDNS and No-IP work well. DuckDNS is free and updates via a curl request, which can be easily automated through cron. In CCcam.cfg or oscam.user, specify the DNS name, not the IP.

Protection: changing default ports and passwords, IP restrictions

The default port 12000 is scanned automatically. Moving CCcam to port 32541 or any other non-standard port is not a panacea, but it reduces noise from bots. In OScam, it's also better not to leave httpport 8888 open to the world.

Inoscam.user the parameterallowedip allows you to tightly bind the account to a specific IP or subnet. If the client has a fixed IP — be sure to use this. Passwords longer than 12 characters, without dictionary words. The defaultadmin/admin in webif is an open door.

Another practical tip: in iptables, allow card sharing ports only from specific IP ranges if the client base is known and limited:

iptables -A INPUT -p tcp --dport 12000 -s 1.2.3.0/24 -j ACCEPT

Diagnostics and solving typical errors

Most problems with the card sharing server are solved through the OScam web interface and reading logs. CCcam is more complicated in this regard — you will have to work with telnet and manual parsing of the output.

Reader status: CARDOK, NEEDINIT, ERROR

In the OScam web interface on the Readers tab, check the status of each reader:

• CARDOK — the card is read, everything is fine
• NEEDINIT — the card is found but not initialized. Checkmhz andcardmhz, try 357 or 600. There may also be a bad contact or power supply of the reader
• ERROR — the reader is not responding. Check the device path (/dev/sci0,/dev/ttyUSB0), file permissions, physical connection
• CARDNOTOK — the card is inserted but not authorized or the subscription has expired

After updating the receiver firmware, the device path may change —/dev/sci0 turns into/dev/sci1 or may disappear altogether. Check vials /dev/sci* andls /dev/tty*.

Error 'card not found' and card initialization issues

If I see "card not found" in the logs with the card physically inserted — the first thing I check isdetect = CD in oscam.server. The parameterdetect indicates which signal means "card inserted." On some readers, you needdetect = 0 instead ofCD.

Another common reason after updates is the incompatibility of the parametersmargoprot. If the smartreader type reader worked before, but stopped after the firmware upgrade — try rebuilding OScam with the same compilation flags.

Freeze of the picture and slow ECM time

Freezing during active card sharing — almost always ECM time. Norm: below 400 ms. At 500–700 ms, short freezes begin when changing CW. Above 700 ms — constant delays.

Causes of high ECM time in order of frequency:

1. A large number of hops (hop ≥ 3)
2. Overloaded or geographically distant peer server
3. Unstable internet channel, high ping, or packet loss
4. Weak processor of the server itself with a large number of clients

If you have multipleC: lines to different servers and ECM time fluctuates — OScam can do load balancing. In oscam.conf in the section[global] the parameterlb_mode = 1 enables automatic selection of the best reader based on ECM time statistics. This works noticeably better than a fixed order in CCcam.cfg.

Connection issues: connection refused, no card

"Connection refused" — the port is closed or the daemon is not running. Check:netstat -tlnp | grep 12000. If empty — the daemon is not listening on the port. Either it is not running, or another port is specified in the config.

"No card" upon successful connection — the client is authorized, but the reader does not respond. Check the reader status in webif.

A separate situation: the internet provider blocks non-standard ports. I've seen this with several mobile operators — all traffic goes through, but port 12000 is silently dropped at the operator level. Diagnosis: check the port's availability from the outside using online tools likeportchecker.co with the client's IP. Solution — change the port or use a tunnel.

Reading OScam and CCcam logs

OScam log by default is written to the location specified inlogfile in oscam.conf. To view in real time:

tail -f /var/log/oscam.log | grep -E "ECM|ERROR|CARDOK"

The logging level is set in[global] with the parameterloglevel = 4 (maximum — 4, includes ECM debug). On a production server, it's better to keep it at 2–3, otherwise the log grows quickly and is hard to read.

The parametercw_check_caid in oscam.conf allows enabling CW cycle checking — OScam will reject suspicious CWs, repeating or zero. This is protection against low-quality peers that provide garbage instead of correct control words.

How to choose a card sharing provider: criteria without names

If setting up your own server with a physical card is not an option, you take "sharing" from a third-party provider. The market is opaque, half of the offers are garbage. You should choose based on specific parameters, not on a pretty website.

And yes: it is legal to use card sharing from third-party servers only if you have your own official subscription for that package. Everything else is a gray area with legal risks that vary by country.

Stability of uptime and declared ECM time

A good provider shows uptime of 98–99% per month and average ECM time below 300 ms. Not on the main page as an advertising slogan, but in the statistics of your specific connection through OScam webif.

Test access for 24–48 hours is a mandatory condition. Without a test in the real conditions of your network, with your receiver, no promises are worth anything. If they don't provide a test — pass by.

Support for necessary packages and local card reader

Clarify not only CAID but also specific providers and transponders. The same CAID can cover different packages on different satellites. Check that the channels you need are indeed decrypted, not just listed.

If you already have a local reader with a card, a normal provider allows setting up fallback: if their server is unavailable, OScam will switch to your local card. This requires support from the provider and correct priorities in oscam.server.

Transparency of conditions and trial period

Look at the conditions in case of downtime. Normal practice is recalculation or extension for long interruptions. Support should respond in a reasonable time, not just until payment.

Access formats can vary: CCcam account (just C: line), newcamd (port + key), sometimes Mgcamd-compatible format. Make sure your receiver and software support the required protocol.

Legal risks and the presence of your own subscription

The legal situation regarding card sharing is ambiguous and depends on the legislation of the specific country. In several European countries, courts have already ruled against operators of illegal card sharing. Using another subscriber's card without their knowledge is no longer a gray area.

If you have your own legal subscription and share it within a home network, that is a fundamentally different situation. Anything that goes beyond one household requires a conscious assessment of risks.