OScam iCAM in 2026: setup and protocol

If you have been working with OScam for a long time and suddenly came across a mention of the iCAM protocol in the documentation or on the forum — you are not alone. Most guides still talk about CCcam, newcamd, cs378x, but they overlook oscam icam 2026. Which is a pity, because for next-generation receivers with DVB-S2X, this is no longer an optional feature, but a working tool.

In this material, I analyze the protocol from the first build of the binary to diagnosing specific errors in the logs. Only specifics: config syntax, real commands, reader statuses.

What is the iCAM protocol and why did it appear in OScam

iCAM is not a network sharing protocol. It is an integrated CAM, implemented directly inside the receiver without a physical CI slot. Instead of a separate module that you insert into a socket, decoding occurs on board — through a software or hardware component, with which OScam communicates as with a reader.

This approach emerged due to the limitations of the classic DVB CI: the old Common Interface does not support the speeds of DVB-S2X, cannot work with multistream transponders, and was generally designed in the era of standard HD. Manufacturers began to integrate CAM logic into the SoC of the receiver, and a protocol was needed to interact with this component.

The history of the emergence of iCAM: from DVB CI to integrated CAM modules

The standard DVB Common Interface (EN 50221) works through a physical slot and a PCMCIA-compatible module. The exchange speed is limited, latency is high, and for encrypted UHD channels with high bitrate, this has become a bottleneck.

Chipset manufacturers — HiSilicon, Amlogic, Broadcom — began to add conditional access hardware blocks directly on the chip. The iCAM protocol was created for interaction with them. OScam gained support for this protocol starting from revision 11704 of the SVN trunk in 2024, and has been steadily developing since then.

How iCAM differs from the standard CCcam/newcamd protocol

CCcam and newcamd are network protocols. They transmit ECM/CW between the server and client over the internet or local network. iCAM is something completely different: it is a protocol for a local reader that is physically (or programmatically) located inside the receiver.

In essence: CCcam = network client-server, iCAM = local decoder. They can be combined in one OScam — and often are. The iCAM reader processes one CAID, while the CCcam client falls back to others.

Which manufacturers of receivers use iCAM (general description)

Receivers based on HiSilicon Hi3798 and Hi3716 series, as well as some platforms on Amlogic S922X, support integrated CAM. Enigma2 boxes on these chipsets are the main target platform for iCAM in OScam. If your receiver is built on one of these SoCs and runs on OpenATV or OpenPLi — the chance that the iCAM reader will work is quite high.

Old receivers based on Marvell or ST Microelectronics — most likely, no.

Preparing OScam to work with iCAM: version, build, dependencies

The first thing to check is the version. Standard binaries from OE-Alliance or OpenPLi are often built without READER_ICAM. It's easy to check:

oscam --build-info | grep -i icam

If the output containsREADER_ICAM — all is well. If the line is missing — you need to rebuild from the source or look for a binary with the necessary flags.

Minimum OScam version with iCAM support (11704+)

iCAM support appeared in revision 11704 of the SVN trunk. It has been working steadily and predictably since 11720+. Check the version of your binary:

oscam --version

Or in WebIF: http://IP:8888 → About. There you can also see what options the binary was built with.

Which modules need to be enabled during compilation

When building from source, you need to ensure that the fileconfig.h (or via./config.sh) has the necessary reader enabled:

# Enable via config.sh:

For cryptography, you needlibcrypto (from the libssl-dev package). The build then:

make USE_LIBCRYPTO=1

Without this flag, AES-128 encryption for network iCAM will not work.

Check iCAM support: oscam --build-info | grep icam

After building or downloading the binary — mandatory check:

oscam --build-info | grep -i icam

If the line is missing — the binary was built without the iCAM reader. The config can be written, but OScam will ignoreprotocol = icam as an unknown protocol.

Where the configs are located

Depends on the distribution:

• Enigma2 OE-Alliance (OpenATV 7.x):/etc/tuxbox/config/oscam/
• OpenPLi 9.x:/etc/oscam/
• manual installation:/var/keys/ or/usr/local/etc/oscam/

Main files:oscam.conf,oscam.server,oscam.user. Inoscam.server is where the entire iCAM configuration resides.

Configuring the reader section for iCAM in oscam.server

This is where most guides on oscam icam 2026 simply remain silent — they do not show the actual syntax. I am correcting this.

Basic syntax: protocol = icam

Reader section inoscam.server looks like this:

[reader]

Parameterprotocol = icam — is key. It signals OScam to use iCAM logic instead of standard CI methods.

Parameters device, caid, boxkey, deskey

device — path to the device in the system. For a physical CAM interface, this is usually/dev/sci0, /dev/sci1, or/dev/ci0. For network iCAM connection — IP address and port in the formatdevice = 192.168.1.100:1234.

boxkey anddeskey — cryptographic keys specific to a particular hardware and conditional access system. There are no universal values — they are either extracted from the firmware or taken from the documentation of the CAM component manufacturer.

caid — identifier of the conditional access system. For example,0500 or0648. Must match what the iCAM component of your receiver actually supports.

Setting up ecmwhitelist and ident for iCAM readers

If you need to restrict the reader to specific providers only:

ident         = 0500:023800,021110

ecmwhitelist — list of allowed ECM commands for a specific CAID and provider. If the channel sends ECM with a command not in this list — the reader rejects it. Helps in case of conflict between several CAM systems on one transponder.

Example of a complete reader section

A more complete version with fallback and caching:

[reader]

detect = cd — method of determining the card by the carrier detect signal.cacheex = 1 enables cache exchange of ECM/CW for the iCAM reader.lb_weight = 200 — priority when load balancing is above average (default 100).

If you need to use a CCcam client simultaneously with iCAM — just add a second reader section:

[reader]

Groups manage routing. For clients fromoscam.user you specifygroup = 1,2 — and OScam decides which reader to use.

Typical errors and diagnostics of the iCAM reader

WebIF OScam on port 8888 — the main diagnostic tool. But before you dive in there, enable normal logging level inoscam.conf:

[global]

debuglevel = 4 includes detailed ECM output. For reader diagnostics, add16 (Reader):debuglevel = 20. After changing — restarting OScam is mandatory.

Reader CARDOK / CARDFAIL — what each status means

CARDOK — the reader is initialized, the card (or iCAM component) is responding. Normal.

CARDFAIL — the reader failed to initialize the card. Reasons: incorrect boxkey/deskey, incompatible firmware, physical problem with the device.

NEEDINIT — the reader is waiting for initialization. Usually seen at startup or after an error. If the status hangs for more than 30 seconds — something is wrong with the device or access rights.

OFF — the reader is turned off. Eitherenable = 0 in the config, or OScam did not find the device at the specified path.

Error ICAM init failed: checking permissions on /dev/ device

Common problem: OScam is running as useroscam ornobody, while/dev/sci0 belongs toroot:video with permissions 660.

# Check permissions:

For a permanent solution — udev rule:

# /etc/udev/rules.d/99-sci.rules

ECM rejected: CAID or provider ident mismatch

If you see in the logs:

[icam_main] CAID 0500 IDENT 021110 -- not found in reader idents

It means the request came from a provider that is not inident of the reader. Either add to the ident list, or remove the ident restriction altogether (then the reader will accept any provider for the specified CAID).

Reading logs: oscam.log + WebIF Status → Readers

# Filtering only iCAM events:

In WebIF:Status → Readers — all readers, their status, the number of processed ECMs, and the percentage of successful CWs can be seen there. If the iCAM reader shows 0 ECM while there are encrypted channels — the problem is in routing (check the group and ident of the client).

iCAM compatibility with DVB-S2X, MIS, and multistream transponders

This is the area where oscam icam 2026 really outperforms older solutions. DVB-S2X with its wide symbol rates and Physical Layer Scrambling is not something that the old DVB CI can handle adequately.

Support for multistream (MIS) ID in iCAM sections

Multistream transponders transmit several independent streams on one frequency through different Stream IDs (ISI). For such transponders, the stream_id must be explicitly specified in the reader section:

[reader]

Withoutstream_id OScam may attempt to decode the wrong stream. The value is obtained from the transponder parameters — it is shown in the tuner settings in Enigma2 or tvheadend.

Working with DVB-S2X modulation and wide symbol rates

DVB-S2X supports symbol rates up to 72 Msymbol/s (compared to 45 for DVB-S2). For the tuner and demodulator, these are hardware requirements. For iCAM in OScam — the main thing is to correctly specify the CAID and ensure that the binary is built with support for wide streams.

Inoscam.conf the parameterpmt_mode affects how OScam receives information about encrypted PIDs:

[global]

pmt_mode = 0 — OScam receives PMT information via socket from Enigma2. For DVB-S2X channels, this is the optimal mode.

The streamrelay parameter in OScam 11704+ for iCAM

For UHD channels with high bitrate, a streamrelay module is often needed. It receives the encrypted stream, sends ECM to the iCAM reader, gets CW, and returns the decrypted stream. Without streamrelay, the receiver's decoder cannot process data in real-time.

[global]

Streamrelay appeared in 11704+, but works stably from 11720. Check for its presence in the binary:oscam --build-info | grep streamrelay.

Known limitations: HEVC 4K UHD channels

The problem is not with the iCAM protocol — it decrypts data normally. The problem lies in the receiver's processor. HEVC 10-bit 4K at 80+ Mbps requires a hardware decoder, and not all Enigma2 boxes with HiSilicon Hi3798MV200 can handle it.

If the picture freezes only on UHD channels — iCAM is not to blame. If the channel does not open at all and there are ECM errors in the logs — then check streamrelay and CAID.

Security and network aspects of iCAM configuration

OScam with open WebIF on 0.0.0.0:8888 — this is a bad idea. I will explain how to fix it.

AES-128 encryption for network iCAM connection

If the iCAM reader is not connected locally (/dev/sci0), but over the network — the ECM/CW traffic needs to be encrypted. In OScam, this is done through parameters in the reader section:

[reader]

Formataeskeys:CAID@IDENT:keyindex:32hex_digitsThe keys must match at both ends of the connection.

Setting httpallowed and httpuser for WebIF

Inoscam.conf, section[webif]:

[webif]

httpallowed restricts access to WebIF only from specified addresses. Without this parameter — WebIF is available to everyone. This is not an option — it is mandatory.

Firewall: which ports to open

Standard ports for OScam:

• 8888 — WebIF (only for local network)
• 1003 — cs378x protocol (if used)
• 12000 — CCcam listener (if OScam is running as a CCcam server)
• 11000 — newcamd (if enabled)

Example iptables for WebIF only from local network:

iptables -A INPUT -p tcp --dport 8888 -s 192.168.1.0/24 -j ACCEPT

Storing boxkey/deskey: permissions 600 on configs

boxkey and deskey are stored inoscam.server in plain text. Therefore:

chmod 600 /etc/oscam/oscam.server

If OScam is run as root (which is a bad idea in itself) — at least permissions 600 are mandatory. Otherwise, any local user or process can read the keys.

If you previously passed by the topic oscam icam 2026 — now you have everything to start: from compiling the binary to analyzing statuses in WebIF. The protocol is operational, the documentation is sparse, but the configs are no more complicated than what you have already configured in classic CCcam.