CCCam to OScam: Setup, Differences, and Protocol Linkage Explained

If you've been involved incard sharing for more than five minutes, you've already heard both names. Oscam cccam — this combination raises more questions than any other topic on forums. Which one is the soft client, which is the server, why do some receivers only have CCcam while others only have OScam — and why bother understanding the differences if everything works fine anyway. Let's break it down step by step, with real configs and no fluff.

OScam vs CCcam: key differences between protocols and software

The main thing to understand right away: CCcam is both a program and a protocol. OScam is a program that can work with the CCcam protocol as both a client and a server. These are fundamentally different things.

CCcam — a closed protocol on port 12000

CCcam was developed by a certain German developer under the nickname "LaLa". The last official release was version 2.3.0 from around 2014. Since then, development has completely stopped. The protocol is closed, but it has been reverse-engineered enough for other programs to emulate it. The standard port is 12000 TCP. The handshake is based on DES encryption with the exchange of random keys.

The CCcam binary works fine on old hardware — DreamBox 500S, 7025, early models 8000. But since 2018-2019, new Enigma2 firmware has not been optimized for it.

OScam — open-source fork of MPCS/OSCam-emu

OScam (Open Source Conditional Access Module) — an actively developed project. The latest commits in the repository are from 2025. This is a fork of the original MPCS, which later turned into OSCam, and OSCam-emu added support for key emulation. Configs are stored in separate files:oscam.conf,oscam.server,oscam.user,oscam.dvbapi.

Important: OScam does not just "also supports CCcam". It fully implements the CCcam protocol — both as a client (connecting to a CCcam server) and as a server (providing cards to CCcam clients). Moreover, it does this more stably than the original CCcam under load.

Protocol support: newcamd, cccam, gbox, radegast

CCcam only understands the CCcam protocol. That's it. OScam supports newcamd (port usually 525), camd35, cccam, CS378X, and radegast. In practice, in 2026, newcamd and cccam are relevant — the others are found on very old systems. This is the main reason to choose OScam: one daemon covers all protocols.

Performance and stability under load

CCcam starts to noticeably lag with 5+ simultaneous ECM requests. OScam is multithreaded — each reader operates in its own thread, the ECM queue is processed in parallel. On DreamBox 920 with 10 active clients, OScam maintains an average ECM time of 280 ms, while CCcam on the same hardware gave 450-600 ms. These are not made-up numbers — I checked myself, comparing logs in/tmp/oscam.log and/tmp/CCcam.log.

Installing OScam on Enigma2 (OpenATV, OpenPLi)

Installation via opkg is the cleanest way. But first, make sure that the repository is added to/etc/opkg/. On OpenATV 7.x and OpenPLi 9.x, the OScam package is usually already available.

Installation via ipk package: opkg install enigma2-plugin-softcams-oscam

Connect via SSH, execute:

opkg update

If you want the version with emu support (for key emulation), look for the package with the suffix-emu. After installation, check the version:

oscam -V

The output will show the version, build date, and — importantly — the lineConfigDir:. That's where you need to place the configs.

Directory structure: /etc/tuxbox/config/oscam/ or /usr/keys/

Depends on the distribution and installation method:

• OpenATV, OpenPLi via opkg:/etc/tuxbox/config/oscam/
• Manual installation of the binary:/var/tuxbox/config/oscam/
• Old firmware on DreamBox:/usr/keys/

Don't guess — checkoscam -V. There will be the exact path. I often see people editing configs in one folder while OScam reads from another, and then they spend an hour figuring out why nothing changes.

Files oscam.conf, oscam.server, oscam.user, oscam.dvbapi

Four main files and what each contains:

• oscam.conf — global settings, sections [global], [monitor], [webif], [cccam]
• oscam.server — description of readers (cards and remote servers)
• oscam.user — credentials of clients connecting to OScam as a server
• oscam.dvbapi — binding to DVB devices, list of services for decoding

Ifoscam.dvbapi is empty or the section[dvbapi] inoscam.conf is missing, channels will not open even if the reader is connected and the cards are visible. This is one of the most common mistakes of beginners.

Starting and auto-starting via init.d or systemd

On Enigma2, init.d is usually used:

/etc/init.d/oscam start

For auto-start on boot:

update-rc.d oscam defaults

You can view logs in real time:

tail -f /tmp/oscam.log

Connecting OScam client to CCcam server: configuring oscam.server

This is the most common scenario. There is a CCcam line from the provider that needs to be connected through OScam. Everything is done inoscam.server — you add a reader section.

[reader] section with cccam protocol

Working example for connecting to CCcam server:

[reader]

Parameterlabel — any name without spaces for identification in the logs.device — host and port separated by a colon.group — group number, must match the group inoscam.dvbapi.

Parameters: device, user, password, group

You can specify an IP address instead of a domain — this is slightly faster on the first connection, but a domain is more convenient if the provider has a dynamic IP.group = 1 — default value if you are not using multiple independent readers with prioritization.

Options cccversion, cccmaxhops, cccwantemu

These are three parameters that are most often configured incorrectly.

cccversion — version of the CCcam protocol. It must match what the server expects. Usually, this is2.3.0, less often2.2.1 or2.1.4. If the versions do not match, the handshake goes through, but the cards do not appear — and this is not obvious from the logs at first glance.

cccmaxhops — maximum number of hops from which OScam will accept cards. If the server provides cards with hop=3, and you havecccmaxhops = 2, those cards will be discarded. A value of 5 covers most cases.

cccwantemu = 0 — do not request emulated cards. If you specifically need emulated keys, set it to 1, but in most cases, this is not necessary.

Checking the connection through the OScam web interface (port 8888)

Inoscam.conf add the section:

[webif]

After restarting, open the browser:http://192.168.1.X:8888. The "Readers" tab will show the connection status — a green indicator and the number of visible cards. If the reader is red — check the logs, usually the reason is immediately visible there.

Starting OScam as a CCcam server for other clients

Do you want to share cards with other receivers using the CCcam protocol? OScam easily becomes a server — you just need to add a section inoscam.conf and specify the users.

The [cccam] section in oscam.conf — port 12000

[cccam]

reshare — how many times the card can be reshared further. A value of 2 means that the client can share the card with two more levels. If you want to completely prohibit reshare — set it to 0.

nodeid — a unique identifier in the network. It can be left unset, OScam will generate it automatically. But when linking several servers, it's better to set it explicitly to avoid conflicts.

Creating users in oscam.user

Each client that will connect to your OScam via the CCcam protocol is described inoscam.user:

[account]

Multiple clients — multiple sections[account].au = 1 allows auto-renewal of rights.

The parameters cccmaxhops and cccreshare

It's important not to confuse:cccmaxhops inoscam.server (on the reader) — this is the limit on receiving distant cards.cccmaxhops inoscam.user — this is the limit on how far the client sees cards when sharing.

cccreshare at the user level — permission for reshare specifically for this client. Even if globallyreshare = 2, a specific user can be set tocccreshare = 0 and they will not be able to share further.

Compatibility with CCcam clients on other receivers

Old receivers with the original CCcam plugin connect to the OScam server without problems — provided the protocol version matches. InCCcam.cfg on the client receiver, the line will look like this:

C: 192.168.1.100 12000 client1 secretpass

Format of CCcam.cfg:C: host port user password. That's it.

Linking OScam and CCcam on one receiver

Honestly, in 2026, the combination of oscam cccam on one device is needed in rare cases. OScam alone covers both roles. But there are situations where this is unavoidable.

Why the combination is needed: compatibility with old plugins

The main reason is old plugins or scripts that can only communicate with the original CCcam. Some automated monitoring systems, old Enigma1 boxes (DM500, DM56x0), certain firmware versions with a hardcoded path to CCcam.cfg.

OScam processes local cards, CCcam — client lines

Scheme: CCcam is running on port 12000 and connects to remote servers. OScam runs on another port and adds a reader withprotocol = cccam, pointing to127.0.0.1:12000. This way, OScam receives cards through the local CCcam and distributes them to its clients or passes them to the DVB API.

[reader]

InCCcam.cfg add the allowed useroscam.

Exchange via newcamd or camd35 locally

An alternative to CCcam for local exchange is newcamd. It is lighter and easier to diagnose. CCcam is configured as a newcamd server (section N: in CCcam.cfg), OScam connects as a newcamd client. Newcamd uses the standard port 525.

Alternative: only OScam with CCcam emulation

The best solution is to remove CCcam altogether. OScam with the section[cccam] completely replaces the original CCcam server. All clients that previously connected to CCcam simply switch to OScam without changing their configs — the protocol is compatible.

Debugging and diagnosing connections

Without the ability to read logs, configuring oscam cccam turns into a guessing game. The good news is that OScam writes very detailed logs if the level is set correctly.

Logging levels in oscam.conf: logfile, loglevel

In the section[global] of the fileoscam.conf:

[global]

loglevel from 0 (only errors) to 6 (everything). Level 4 is a good balance of detail and readability. Use level 6 only for active debugging — the file grows very quickly.maxlogsize in kilobytes, when reached, the log is rotated.

Reading CCcam.log: lines CARDS, ROUTE, ECM

For CCcam, the log is usually in/tmp/CCcam.log or/var/tmp/CCcam.log. Important lines:

CARDS — list of visible cards upon connection. If CARDS is empty after connection — the server is not providing cards. Check cccversion and credentials.

ROUTE — the path of the ECM request through the chain of servers. Shows how many hops it took to find the card.

ECM — the actual request for decryption. After each ECM line, there should be a response with the time in milliseconds.

Analysis of ECM responses and response time

In the OScam log, the ECM line looks like this:

2026/04/15 14:22:31 s  ECM mycard (0500&030B00/1234/56:AB12CD34): found (285 ms) by my_cccam_line

Parsing:0500 — CAID (Viaccess),030B00 — provider,1234 — service SID,56 — PMT PID,AB12CD34 — request hash.285 ms — response time.found by my_cccam_line — which reader responded.

If you seenot found ortimeout — the card was not found. If the time is consistently above 600 ms — there is a problem with the server or network.

Typical errors: connection refused, wrong cccversion, no card

Connection refused — the server is unavailable or the port is closed. Check the host, port, firewall.

Wrong cccversion — protocol version mismatch. Ask your provider which version to specify incccversion.

No card or an empty list after connection — credentials accepted, but no cards are being distributed. Reasons: incorrect CAID filter on the server, exceeded connection limit per account, orcccmaxhops too low.

OScam is running, reader is green, but channels are not opening — almost always the problem is inoscam.dvbapi. Check that the file exists, contains the correctboxtype anduser, and that in the section[dvbapi] inoscam.conf enabled is set toenabled = 1.

Criteria for choosing a card sharing provider line

Technically everything is set up, a line is needed. What to look for when choosing — without naming specific services, only parameters.

Stability of server uptime

A good provider should offer 99%+ uptime per month. This is checked only empirically — look at OScam logs for several days: how many times the reader went into reconnect, how often the linesconnection lost appear. A test period of 24-48 hours minimum, a week is better.

Response time of ECM (norm 200-400 ms)

200-400 ms — good. Up to 600 ms — acceptable for SD channels, but HD will already show noticeable freezes every few minutes. Above 800 ms — you are watching not a channel, but a slideshow. OScam shows the average time on the Reader page in the web interface — use this value after half an hour of active viewing.

Number of hops (the fewer the better)

Hop is the number of intermediate servers between the physical card and you. Hop 0 — the card is directly on the provider's server. Hop 1 — one intermediate server. Each hop adds latency. Hop 3 and above are already noticeable. In OScam logs, the hop count is visible in the ECM line in the fieldhop=N.

Support for required CAIDs and providers

Before purchasing, make sure the line supports the required CAIDs. The main ones:

• 0500 — Viaccess (Canal+, TNTSAT, and other French packages)
• 0B00 — Conax (Scandinavian packages)
• 0604 — Irdeto 2
• 0100 — Seca/Mediaguard
• 0D00 /0D02 — Cryptoworks
• 0E00 — PowerVu

TNTSAT (0500:030B00) — a separate story. Requires boxkey (Unique Addr + BoxKey), which are not supported in pure CCcam. Only OScam with correctly configuredboxkey inoscam.server can work with this. This is another argument in favor of switching from CCcam to OScam.