iCam and OScam: setup, configs, and differences in 2026

If you have been dealing with card sharing for more than five minutes, you have already come across the confusion surrounding icam oscam. Is it the same thing? A fork? A competitor? Most forums write three words about it and provide a download link. Here we will break it down properly: architecture, configs, diagnostics, security — everything you need for a working stack in 2026.

What is iCam and its connection to OScam

OScam is an open-source conditional access manager, a successor to OSCAM (Open Source Conditional Access Module). Written in C, it supports dozens of protocols and is considered the de facto standard for serious installations. iCam grew out of it as a separate build with specific goals.

The origin of iCam as a fork of OScam

iCam started as a patch set on top of the main branch of OScam. The developers added support for additional EMU modules, expanded the list of supported smart cards, and accelerated the key update cycle. Essentially, it is the same engine, but with a different set of patches and a different release policy.

This is not a competing project from scratch. The codebase is 90% identical to OScam. The difference lies in the details of EMU implementation, the frequency of updates, and which pull requests the maintainers accept.

Key differences from classic OScam

Classic OScam is a conservative project. Patches undergo long testing, and EMU functionality is moved to a separate branch (OScam-EMU). iCam is more aggressive: EMU patches are included by default, keys are updated more frequently, and the build sometimes contains experimental fixes that have not yet been accepted into the mainline.

This means less stability but more relevance. For the user, this means: if your provider has changed keys and classic OScam has not yet caught the update — iCam may handle it sooner.

Supported platforms and receivers

Both builds work on Enigma2, DreamOS, VTi, ATV. Binaries for receivers are distributed in ipk (Opkg) formats, AppImage for x86/x64 Linux servers, and are compiled from source for any architecture.

An important nuance: iCam binaries are sometimes built under a newer glibc than what is on older ARM receivers (VU+ Solo 2, DM800). In this case, the launch will end with an errorversion 'GLIBC_2.33' not found. The solution is to build from source directly for the target platform or choose an older version of the binary.

When to choose iCam and when to choose OScam

OScam: if maximum stability is needed, the server is running in production, and EMU updates are not critical. iCam: if you are chasing current EMU keys or want the latest compatibility patches.

In practice, for a sharing server with real cards, the difference is minimal. icam oscam is more of a choice based on personal preferences and which build is easier to obtain for your platform.

Installing iCam/OScam on a receiver and Linux server

Let's go through the actual commands. No poetry.

Installation on Enigma2 (ipk package)

Download the ipk package for the architecture of the receiver (mipsel, armv7, aarch64). Then:

opkg install oscam_*.ipk

After installation, the configs are located in/etc/tuxbox/config/. There you will also find oscam.conf, oscam.server, oscam.user. The DVBAPI plugin is automatically picked up by Enigma2 through/tmp/camd.socket.

Building from source on Debian/Ubuntu

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

Create the config directory manually:mkdir -p /usr/local/etc/oscam.

Launching via systemd unit

Here is a working unit file. Place it in/etc/systemd/system/oscam.service:

[Unit]

Launch:

systemctl daemon-reload

Directory structure: /etc/tuxbox/config/ and /usr/local/etc/

On Enigma2 receivers:/etc/tuxbox/config/ — main directory. On Linux servers:/usr/local/etc/oscam/ or any directory passed via the flag-c. Working files (logs, pid, cache) go to/tmp/.oscam/.

Access rights and process owner

Configuration files with passwords — strictly 600:

chown oscam:oscam /usr/local/etc/oscam/*

Running as root — a bad idea. Create a separate user:useradd -r -s /bin/false oscam.

Basic configuration: oscam.conf, oscam.server, oscam.user

Here most tutorials have failed — they show configs without explaining what each parameter means. We correct this.

oscam.conf — global parameters and WebIF on port 8888

[global]

httpallowed = 127.0.0.1 — mandatory. Opening WebIF on the internet without this parameter is not allowed under any circumstances.

oscam.server — description of readers and protocols (cccam, newcamd, cs378x)

[reader]

inactivitytimeout — how many seconds of inactivity before the connection is dropped. 30 seconds is a reasonable default for unstable links.lb_weight affects the load balancer: the higher the weight, the more often OScam accesses this reader.

oscam.user — client accounts and groups

[account]

uniq = 4 — prohibits re-login with the same credentials. Essential for public servers, otherwise one account can be accessed by dozens of people.

oscam.dvbapi — CAID mapping for direct decryption

[dvbapi]

Parameterboxtype is critical. For VU+ setvu, for Dreambox —dreambox, for DM900 —dm900. Incorrect boxtype — and DVBAPI will not start even with everything else perfectly configured.

oscam.services — grouping channels by provider

[PROVIDER1]

This file is useful when you need to restrict access for a specific user to certain channels or providers. In simple configurations, it can be omitted.

Protocols and ports: CCcam, Newcamd, CS378x, GBox

Each protocol exists for its own reason. Let's get to the point.

CCcam protocol: port 12000 and hops exchange

CCcam operates on port 12000 by default. Handshake: the client connects, the server provides a list of available CAID/providers through the "hops" mechanism. Each hop is one node in the key exchange chain.cccmaxhops = 3 means that OScam will accept cards no deeper than the third level.

CCcam works well over the internet with an unstable connection. The protocol can reconnect and supports keepalive. However, it is heavier on traffic and more complex to diagnose than simpler alternatives.

Newcamd: individual ports for CAID

Newcamd is historically older than CCcam. Each CAID gets its own port — in the config, it looks likeport = 15050@0500:000000. The protocol is well supported by older CAM modules and receivers from the early 2010s.

Encryption in newcamd is weaker than in CS378x. For the new stack, I recommend CS378x, leaving newcamd only for compatibility.

CS378x (camd35 over TCP): reliability and encryption

CS378x is camd35 over TCP with encryption. It operates on port 15000 (by default). Faster than CCcam on a local network, better withstands instability than raw UDP camd35. Latency is usually 5–15ms compared to 20–50ms for CCcam on distant servers.

[reader]

DVBAPI for local decryption on the receiver

DVBAPI is not a sharing protocol, but an interface between OScam and the receiver's demultiplexer. OScam receives ECM from the tuner via socket/tmp/camd.socket, decrypts it, and sends it back. No network — everything is local. This is the fastest way to operate on the receiver.

When to use which protocol

• CCcam — connection to a remote server over the internet, compatibility with most providers is needed
• CS378x — local network or VPN with trusted peers, speed is needed
• Newcamd — old equipment specifically requires this protocol
• DVBAPI — local decryption on the receiver with Enigma2

Diagnostics and solving typical problems

80% of problems with icam oscam can be solved by reading the logs. It sounds trivial, but most people either do not look at the logs at all or look in the wrong place.

Log analysis through /tmp/.oscam/oscam.log

# Live log tail:

Level-d 255 outputs everything including ECM bytes. Do not keep it in production — the log grows in minutes. Use only for diagnosing a specific problem.

Connection refused error and checking iptables

If you see in the logConnection refused orConnection timed out — first check the firewall:

# Open CCcam port:

Ifss shows that OScam is not listening on the port — the problem is in the config, not in the firewall. Check the section[reader] and the syntax of oscam.server.

ECM timeout: setting ecmnotfoundlimit and lb_min_ecmcount

In the log you seeECM: not found orECM time: timeout? Options:

[global]

ecmnotfoundlimit = 10 means that after 10 unsuccessful ECMs OScam will switch to the next reader. A small value — frequent switches, but faster response to a dead reader.

Card not found and checking CAID/SID

Open WebIF (http://127.0.0.1:8888), go to Readers → your reader → Cards. If the card is not displayed — the reader is not authorized. Check the login/password and CAID compliance.

Typical error: the reader is connected, cards are present, but the channel is not decoded. The reason — the channel's SID is not in the allowed list on the server side. This is a problem on the provider's side.

Freeze of images: lb_savepath and reader balancing

[global]

OScam saves ECM time statistics and selects the reader with historically the best latency at the next start. If the freeze continues — check the ping to the server. More than 100ms for HD channels is already a problem. For 4K content, a comfortable threshold is up to 50ms.

Security and optimization of operation

Most tutorials on icam oscam end with "started, works". This is a mistake — an open OScam on a VPS is a hole.

WebIF restrictions: httpallowed and httpuser/httppwd

[webif]

Change the port from the default 8888 to a non-standard one. Bots scan specifically for 8888. On a non-standard port — silence. And never leave emptyhttpuser/httppwd — this is an open WebIF for anyone who knows the port.

Critical error I have seen several times: a person changeshttpallowed in WebIF through the browser, saves, and loses access to WebIF forever because they did not restart OScam to apply the changes. Always edit oscam.conf directly and dosystemctl restart oscam.

Fail2ban for protection against brute force on the WebIF port

Create/etc/fail2ban/filter.d/oscam.conf:

[Definition]) rejected.*) authentication failed.*

Then in/etc/fail2ban/jail.local:

[oscam-webif]

Aftersystemctl restart fail2ban — five failed attempts in 10 minutes block the IP for an hour.

Configuring cacheex to reduce load

[reader]

cacheex_mode = 2 — two-way cache exchange with trusted peers. OScam caches decrypted CW and provides them to other servers without re-querying the card. The load on the reader decreases significantly.

But be careful: cacheex with an unreliable peer can lead to OScam crashing or receiving garbage CW. Enable only with trusted partners.

Monitoring via MRTG or Grafana

OScam can provide statistics through the Monitor API on port 988. The Prometheus-exporter for OScam can be found on GitHub — it parses WebIF and exports metrics: number of active clients, ECM time, number of errors per reader.

In conjunction with Grafana, you get a dashboard with history. I configured such a stack and it really helps catch the moment when the reader starts to degrade long before users complain about freezing.

Regular log rotation via logrotate

# /etc/logrotate.d/oscam

Without rotation, the log for several weeks of operation will take several gigabytes. On a VPS with a small disk, this is critical.

---