Enigma2 setup top 2026: CCcam and OScam setup — complete guide to card sharing

If you googled something like enigma2 setup top, it means the receiver is already under the TV, the line for card sharing has been received or will arrive soon, and the standard manuals from the internet do not work for your image for some reason. This is normal. Enigma2 is not a single product, but a whole family of images with different paths to files, different menus, and different names for managing emulators. I have set up CCcam and OScam on a dozen different boxes — from old Dreambox to modern GigaBlue and Zgemma — and in this guide, I will outline the working sequence of actions, not just general words about "turn on card sharing and everything will work."

This article is aimed at those who already understand what a receiver and satellite dish are and want to deal with configs, ports, and logs without unnecessary fluff. We will go through the architecture, access to the box, installation of CCcam and OScam, diagnosing the black screen, and what to look for when choosing a line source.

What is Enigma2 and how card sharing works

Enigma2 is a Linux-based firmware (image) that runs on most modern satellite and IPTV receivers: Vu+, Dreambox, GigaBlue, Zgemma, Edision, and so on. Enigma2 itself is a graphical interface and a set of services for the tuner, EPG, recording, and plugins. Card sharing is added separately through a so-called softcam emulator.

The role of Enigma2, emulator, and card receiver

The classic scheme without sharing is simple: a smart card is inserted into the receiver, the tuner receives an encrypted stream, the card decrypts the control word (CW) through a built-in CI module or card reader, and the Enigma2 demultiplexer receives the CW directly. In card sharing, the card is physically located on one server (usually at the line provider), and the CW is transmitted over the network through the emulator — CCcam or OScam. The emulator receives the ECM packet from the receiver, sends it to the server, receives the decrypted CW back, and substitutes it to the demultiplexer as if the card were local.

The difference between CCcam and OScam

CCcam is a proprietary, closed protocol and software of the same name. It is old (the first versions appeared back in the mid-2000s), simple to set up — essentially, one line of C-line — and is still widely used precisely because of this simplicity. Downsides: closed code, sparse logging, limited flexibility.

OScam is an open project (a fork of CCcam / Newcamd ideas) that supports dozens of protocols simultaneously: cccam, newcamd, radegast, constcw, and others. It logs each ECM request in detail, can work as both a client and a server simultaneously, and generally provides much more control. Many system administrators keep both emulators and switch depending on which protocol a specific line source provides.

How the softcam emulator interacts with the image

The emulator is a separate binary that runs as a daemon and communicates with the Enigma2 kernel through the socket camd.socket (usually /tmp/camd.socket) or through the built-in softcam mechanism of the image. This is why you cannot just copy the binary and hope everything will work — the image must "know" that this specific emulator is active and not another. This is managed through the Softcam / Cam Manager menu or through init.d scripts, which will be discussed below.

Preparation: access to the receiver via FTP and Telnet/SSH

Before diving into configs, you need proper access to the box's file system. Here, almost everyone stumbles on the same thing — not on protocols, but on file encoding and access rights. Let's break it down step by step.

Determining the receiver's IP address on the network

Go to the Enigma2 menu: Menu → Network → Network Setup (in OpenATV, this is usually Menu → Settings → Network). There, you can immediately see the current IP obtained via DHCP. If the router supports IP reservation by MAC — immediately assign it to the receiver, otherwise, after rebooting the box, the IP may change, and all your scripts with hardcoded addresses will stop working.

Connecting via FTP (port 21) for editing configs

For editing text files, FileZilla is the most convenient. Connect to port 21, login as root, password — either empty or root, depending on the image. Then go to /etc/ or /usr/keys/, view and edit the necessary files right there, without downloading them to your computer (FileZilla supports a built-in editor — double-click opens the file in a text editor, and after saving, it uploads the changes back automatically).

Access via Telnet (port 23) or SSH (port 22) for commands

To restart processes and view logs in real-time, access via command is needed — Telnet (port 23, unencrypted) or SSH (port 22, if the image supports it). From Windows, PuTTY is most often used, from Linux/macOS, the built-in terminal is sufficient — just ssh [email protected] or telnet 192.168.1.50. Through this console, you can conveniently view tail -f /tmp/oscam.log or restart softcam scripts without rebooting the entire box.

Determining the installed image (OpenPLi, OpenATV, etc.)

You can check the version and name of the image in Menu → Information → About or with a command in Telnet: cat /etc/image-version or cat /etc/issue. This is important because OpenATV, OpenPLi, VTi, BlackHole, and other builds have different paths to plugins and different Softcam menu structures. Do not rely on screenshots from other guides — compare with the actual paths on your box.

Installing and configuring CCcam on Enigma2

CCcam still remains the fastest way to get a working line on Enigma2 if you already have the C-line data from the source. Let's break down the installation step by step.

Installing the CCcam binary and softcam script

The CCcam binary is usually placed in /usr/bin/ (sometimes /var/bin/ on older images). After uploading via FTP, you almost always need to manually set execution rights — more on that below. The controlling script is located in /etc/init.d/softcam or /usr/script/. In most modern OpenATV/OpenPLi builds, the emulator is managed by the Softcam / Cam Manager menu item — it automatically inserts the necessary binary into autostart, and you do not have to manually go into init.d.

Structure of the CCcam.cfg file and C-line

The main config is CCcam.cfg. The format of the C-line is simple:

C: host port username password

For example: C: 185.23.xx.xx 12000 user123 pass456. Each line is a separate source (server from which you receive the line). You can add several C-lines in a row, CCcam will automatically choose the best one based on priority and availability.

Key parameters: port, DES-key, separators

In addition to the C-line, CCcam.cfg configures: PORT (the local port on which the receiver will distribute the line further if you are sharing it), as well as NODE ID and, in some versions, DES keys for encrypting peer connections (F-line, N-line). For basic client configuration, which simply consumes the line, usually one C-line and the web interface port parameter are sufficient.

Paths for placement: /usr/keys/ and /etc/CCcam.cfg

This is where the main confusion lies for newcomers. In some images, CCcam looks for the config in /etc/CCcam.cfg, in others — in /usr/keys/CCcam.cfg. The binary always works according to a fixed, hardcoded path — it cannot be guessed, but it can be easily checked: open the softcam script (usually /etc/init.d/softcam or a file in /usr/script/) and see what path is passed to the emulator in the launch parameter. That is where you need to place the config.

Starting and stopping the emulator through the menu and Telnet

Through the menu: Menu → Setup → Softcam / Cam Manager → select CCcam → Activate. Through Telnet: /etc/init.d/softcam restart or killall -9 CCcam followed by manually starting the binary. After any changes to CCcam.cfg, the emulator needs to be restarted — simply saving the file does nothing, the config is read only at the start of the process.

You can check if the line is alive through the built-in CCcam web interface — open in your browser http://IP_receiver:16001 (standard port if it hasn't been changed). There you can see the list of C-lines, their status (CONNECTED / STANDBY), and the number of open channels for each line.

Installation and configuration of OScam on Enigma2

If CCcam is "one line and hope," then OScam is a full-fledged server with flexible settings and a clear log. Let's break down three key files.

Configuration files: oscam.conf, oscam.server, oscam.user

All three files are usually located in /etc/tuxbox/config/ (less often /usr/keys/ or a separate folder specified by the launch parameter -c). oscam.conf is responsible for the global settings of the process, oscam.server describes connections to external sources (readers), and oscam.user is for local clients to whom you distribute the line.

Configuration of [webif] and access to web status (port 8888)

In oscam.conf, we look for the section [webif] and write:

httpport = 8888
httpuser = admin
httppwd = your_password

After restarting the emulator, the status is available at http://IP_receiver:8888. This is perhaps the most underrated diagnostic tool — it shows all readers, their status, the time of the last ECM response, and the number of errors.

Adding a reader via the newcamd/cccam protocol

In oscam.server, we add the block:

[reader]
label = server1
protocol = cccam
device = 185.23.xx.xx,12000
user = user123
password = pass456
group = 1
cccversion = 2.3.0

If the server provides the line via the newcamd protocol, change protocol = newcamd and add key (DES key) instead of the user/password pair in some configurations. Check the format with the line source — parameters differ depending on the protocol.

Paths: /etc/tuxbox/config/ and /var/keys/

In addition to configs, OScam uses /var/keys/ for key files (for example, SoftCam.Key for DVB-CSA packages, if local emulation without a server is required). Check the CONFDIR parameter in the emulator's startup script (/etc/init.d/softcam or similar) — it determines which folder OScam actually reads at startup.

Checking ECM/EMM in the oscam.log

The log is usually located in /tmp/oscam.log or /var/log/oscam.log. We check with the command tail -f /tmp/oscam.log. A successful response line looks something like this:

ECM (fta) 06E0 3800 CAID 0500 found (127 ms) by server1

Here, two points are important: the status found (not found does not mean a network problem — it means that the requested packet is not available on this line) and the time in milliseconds — this is the actual response speed of the server, the main indicator of the quality of the source.

Diagnostics: why channels do not open

A black screen with the message "no signal" or a frozen loading indicator — this is always the same verification algorithm, just different people do not get to it in order.

Black screen and line status 'off'

First of all — the web interface. For CCcam, this is port 16001, for OScam — the one you specified in [webif] (in the example above 8888). If the reader or C-line shows status OFF or DOWN — there is no point in troubleshooting the decoder, the problem is at the connection level.

Checking connection with the server (ping, telnet to port)

From the receiver's Telnet, execute telnet host port, where host and port are the same as in the C-line or in device= in the reader. If the connection cannot be established — either the server is unavailable, or the port is closed by a firewall (on your side or the line provider's), or the IP is incorrectly specified. A regular ping is also useful, but remember that ICMP can be blocked even with a working TCP port — focus on telnet.

ECM errors: timeouts and 'not found'

If there is a connection to the server, but the channel is still black — check the log. not found means that the server received the ECM but could not (or does not have the right to) decrypt it — this may be a problem on the line side, not yours. Timeout means that the request was sent, but no response was received — this is already about network quality or server overload.

Conflict of two emulators running simultaneously

A classic mistake — CCcam and OScam are both running on the box at the same time, both trying to occupy the same socket camd.socket. In the log, this looks like constant connection drops without an apparent reason. Check via ps | grep cam in Telnet — if there are two emulator processes in the list, one of them needs to be stopped through the Softcam menu.

File permission issues (chmod 755)

After uploading the binary via FTP, execution permissions are often reset. This can be resolved with one command in Telnet: chmod 755 /usr/bin/CCcam (or the path to your OScam binary). Without this step, the startup script simply fails silently, and the log is silent.

How to choose a reliable line source: criteria, not names

I intentionally do not name specific services — the card sharing market is unstable, and the criteria for selection are more important than a specific brand. Here’s what you should really pay attention to.

Stability of uptime and ECM response time

Look not at promises, but at the real numbers in your oscam.log. An ECM response time in the range of tens of milliseconds is a good sign. If you consistently see 800-1500 ms or higher, or frequent timeouts — the source is overloaded or the network between you and the server is poor.

Support for necessary packages and local cards

Before connecting, clarify with the source which specific packages and card providers it supports — this should match what you are actually watching. Universal promises of "everything works" without specifics are a bad sign.

Trial period and technical support

A normal practice is a short trial access for several hours before paying for a long line. This allows you to check exactly what matters: the real ping of ECM during prime time (in the evening when the load is maximum), not at three in the morning when the server is half-empty.

Signs of an unstable or resold source

Freezes specifically during evening hours, increasing ECM response time with the same set of channels, frequent unscheduled line drops — all these are typical signs that more connections have been sold on the server than it can handle. If this happens regularly — the source needs to be changed, regardless of how good everything looked in the first week.