Cardsharing: setting up CCcam and OScam from scratch 2026

If you are engaged in cardsharing, setting up CCcam OScam is a topic that most resources explain through copy-pasting configs without a single word about what happens inside. This article is not about "download and connect." Here is the mechanics, real paths to files, decoding of each parameter, and diagnostics when something goes wrong. The material is technical and educational in nature. The legality of use entirely depends on the presence of a legal subscription by the card owner and the jurisdiction in which you are located.

What is cardsharing and how does it work technically

The mechanics are simple, but fully understanding it is half the success in setup. The receiver receives an encrypted DVB stream. To decode a frame, it needs a control word (CW) — an 8-byte key that changes every 10 seconds. This key can only be obtained by decrypting the ECM packet (Entitlement Control Message) using a physical smart card.

If the card is not available locally, the receiver sends the ECM to a remote server, which processes it through a real card, obtains the CW, and returns it back. The receiver decodes the stream. That's all cardsharing in two sentences.

The principle of exchanging control words (CW) between the server and the client

The client connects to the server via TCP, sends an ECM request, and receives the CW. The time from sending the ECM to receiving the CW is called ECM time. If it exceeds ~800–1000 ms, freezes begin because the receiver does not have enough time to prepare the key for the next frame. Stable operation is an ECM time in the range of 100–300 ms.

The role of ECM and EMM in the decryption process

ECM is a request for CW, it goes constantly, every 10 seconds. EMM (Entitlement Management Message) are packets through which the provider manages card rights: activates, updates subscriptions, adds channels. EMM is processed only in the presence of a physical card. Without a card, EMM packets are simply ignored — this is normal for the client side.

The difference between CCcam, newcamd, and CS378x protocols

CCcam uses its own binary protocol over TCP, with a default port of 12000. The protocol is closed but has been reverse-engineered for a long time. Newcamd operates on port 15050 (or any other) with DES encryption — older but widely supported. CS378x (Camd35) is another protocol that works over UDP and is popular in some regions.

OScam supports all three for both receiving and sending. CCcam only supports its own protocol. Therefore, OScam as a daemon is more flexible — it acts as a universal proxy between protocols.

Where the boundary between legal and illegal use lies

Legal scenario: you own a subscription, the card is physically with you or with an authorized person, you distribute CW to your own receivers in your home network. Illegal: the card belongs to someone else, and you use it without an agreement with the rights holder. The technical setup is the same in both cases — legal responsibility is different.

Installation and basic setup of OScam

OScam is what is currently actually used in production on Enigma2 set-top boxes. CCcam has not been updated since 2014. OScam is actively supported by the community, and the latest builds can be found for specific architectures (mips, arm, aarch64).

Building OScam from source and ready binaries for Enigma2

If you want to build it yourself, you need a cross-compiler for the target architecture of the set-top box. For most modern boxes, this is arm-linux-gnueabi or aarch64-linux-gnu. The OScam repository is located at svn.streamboard.tv/oscam. The build command with a minimal set of modules:

make allinone USE_LIBUSB=0 USE_PCSC=0 OSCAM_CONF_DIR=/etc/tuxbox/config/oscam

But honestly, for Enigma2, it's easier to take a ready ipk package from the repository of your image (OpenPLi, OpenATV, OpenVision). It is installed viaopkg install oscam, the binary will be placed in/usr/bin/oscam.

The structure of the directory /etc/tuxbox/config or /usr/keys

OScam configs usually reside in/etc/tuxbox/config/oscam/ on OpenPLi and its derivatives. On some images —/var/keys/ or/usr/keys/. The exact path is set at startup with the flag-c. The minimum set of files in this directory:

• oscam.conf — global settings and web interface parameters
• oscam.server — description of readers (cards, remote servers)
• oscam.user — users who connect to OScam as clients
• oscam.dvbapi — decoding priorities for Enigma2
• oscam.srvid — database of caid/provid channel mappings

File oscam.conf: sections [global], [webif], [newcamd]

Minimum workingoscam.conf:

[global]

Section[newcamd] you add if you want to accept connections from clients using this protocol. Section[cccam] — if you want to share using the CCcam protocol.

Starting the daemon and checking via the web interface on port 8888

Starting manually:

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

Flag-b — background mode. After starting, open the browser:http://IP_set-top_box:8888. In the web interface, you see readers, card status, active clients, and the latest ECM requests. If the reader shows status "CARD OK" — the card is being read. If "OFF" or "ERROR" — check the log.

Setting up CCcam server and client

CCcam is still widely used as a protocol (not as a daemon). Understanding its syntax is necessary at least because OScam can work with it from both sides.

Files CCcam.cfg, CCcam.channelinfo, and CCcam.providers

Main config —/etc/CCcam.cfg. The other files are optional:CCcam.channelinfo contains channel names for display in logs,CCcam.providers — description of providers. OneCCcam.cfgis sufficient for operation.

C-line strings for the client and F-line for the server

C-line — this is a connection to a remote server. Syntax:

C: hostname 12000 username password

F-line — this is granting access to your clients:

F: clientuser clientpass 1 0 0

Here, the three numbers are not magic. The first (1) — uphops: how many servers the card was received through before it started being shared. The second (0) — downhops: how many hops the client is allowed to pass on. The third (0) — whether to allow the client to share their local cards in the reverse direction. For a standard client:1 0 0.

Standard port 12000 and its change

By default, CCcam listens on port 12000. It is changed by a parameter in the config:

SERVER LISTEN PORT: 15000

After changing, you need to update the C-line for all clients and forward the port on the router. If there is a firewall on the server — open the new port in iptables:

iptables -A INPUT -p tcp --dport 15000 -j ACCEPT

Parameters F: { 1 1 1 } and limiting the number of hops

If you set downhops = 1 — the client will be able to pass the card to another client below. This creates a chain of hops. Each hop adds latency. In practice, more than 2 hops — is already unstable. Keep downhops = 0 if you don't want client proliferation.

Restarting CCcam after editing the config:

killall CCcam&& sleep 2&& CCcam&

Logs can be viewed here:/tmp/CCcam.log or/var/log/CCcam.log depending on the configuration.

Linking OScam and CCcam: hybrid configuration

Here is a section that most sites skip. Namely — how to simultaneously receive CW from a remote CCcam server and read a local card through OScam, setting priorities. This is the real cardsharing setup of CCcam OScam in hybrid mode.

Description of [cccam] reader in oscam.server

For OScam to connect to the CCcam server as a client, inoscam.server a reader with the cccam protocol is added:

[reader]

The parametergroup links the reader with users. The parametercaid — which encryption systems to service through this reader. Leaving it empty means "everything". But it's better to specify specifically — this reduces unnecessary ECM requests.

File oscam.user and client binding

Inoscam.user describes the clients that connect to OScam:

[account]

Throughgroup you control which readers each client has access to. A client with group=1 only works with readers in group 1. This is convenient for separating the local card and the remote server.

The oscam.dvbapi file for working with Enigma2

This file manages which providers and caid Enigma2 processes and in what priority:

P: 0500:023800

LinesP: — providers (caid:provid) in order of priority. The lineI: — ignore this caid. If you have several active caid and the receiver tries to decode the wrong one — this is corrected here.

An important point: if both CCcam and OScam are running simultaneously — they compete for control of dvbapi. Two demons cannot listen to one dvbapi socket at the same time (/tmp/camd.socket). You need to choose one. Usually, OScam is left and configured as the only entry point.

Routing requests between protocols

OScam routes ECM requests by groups and caid. The logic is as follows: an ECM with caid 0500 arrives → OScam checks which readers in the client's groups service this caid → sends the request to the appropriate reader → receives CW → returns it to the client. If the reader does not respond within the timeout — it tries the next one in the group. This is the failover when one server goes down.

Diagnostics and troubleshooting typical errors

The actual cardsharing configuration of CCcam OScam always ends with a diagnostic session. This is normal. Here is a practical order of actions.

Error 'card not found' and checking caid/provid

In the OScam logs, we look for lines like:

ECM caid 0500, provider 023800, reader remote_cccam: CARD NOT FOUND

The first step is to compare caid and provid with what is actually coming from the server. In the OScam web interface (port 8888, section "ECM history") you can see what is being requested. Then you openoscam.srvid and check that the required caid:provid pair is there and corresponds to the channel.

The second step is to check that the reader actually services the required caid. Look at the section[reader] inoscam.server. If the fieldcaid is empty — the reader accepts everything, but that does not mean that the server on the other end services it.

One non-obvious scenario: the provider changed broadcasting parameters and caid/provid changed. It was 0500:023800, now it is 0500:032830. The receiver sends the old request — the server does not recognize it. Solution: updateoscam.srvid and restart the daemon.

Freeze of images and green screen: ECM time problem

Freezes with an established connection — almost always ECM time. You check in the OScam web interface, the "ECM time" or "response time" column for the reader. If it is consistently more than 600–800 ms — the problem lies in the channel to the server or in server overload.

Checking network latency is trivial:

ping -c 20 hostname_server

If the ping is 20–30 ms and ECM time is 900 — the server is overloaded. If the ping is 300+ ms — the problem is in the channel. Another reason for freezes: desynchronization of system time on the receiver. EMM packets and some encryption systems are sensitive to time discrepancies greater than 30 seconds. You check:

date

If the time is significantly off — synchronize and restart OScam.

Connection refused: firewall, NAT, and port forwarding

The client cannot connect — diagnose from the outside:

telnet hostname 12000

IfConnection refused — the port is closed on the server side or not listening. Iftimeout — the firewall or NAT is blocking. You check on the server:

netstat -tlnp | grep 12000

The worst case — double NAT by the provider (CGNAT). Then port forwarding through the router is not enough — the provider is also behind NAT and your external IP is not routed directly. In this case, the only working options are: ask the provider for a public IP (for a fee), rent a VPS and set up a reverse tunnel via SSH or WireGuard, or use a service like ngrok for port forwarding — but this is already exotic for a permanent server.

A reverse SSH tunnel with VPS looks like this:

ssh -R 12000:localhost:12000 user@vps_ip -N

Then clients connect to VPS:12000, the traffic is tunneled to you.

Analyzing OScam logs: debug levels and filtering

By defaultdebug = 64 inoscam.conf — this is a normal level for operation. For diagnostics, you setdebug = 255 — you get everything, including every ECM request. The log is written to the file specified in thelogfile parameter.

Filtering the needed information is convenient through grep:

tail -f /tmp/oscam.log | grep "ECM\|caid\|ERROR"

The fileecm.log (if enabled by theecmlog = 1 parameter) contains the history of all requests with timestamps — convenient for retrospective analysis.

If the receiver has outdated Enigma2 firmware — the current version of OScam may not start due to library incompatibility (glibc). In this case, either update the firmware or use a statically compiled OScam binary without dependencies on system libraries. Static builds are usually slightly heavier but work on any firmware.