OScam vs CCcam: сравнение протоколов и софта 2026

Если вы занимаетесь card sharing больше пары месяцев, вопрос oscam vs cccam рано или поздно встаёт ребром. Обе программы решают одну задачу — раздавать расшифрованные control words клиентам — но делают это по-разному, с разной надёжностью и совершенно разным уровнем поддержки в 2026 году. Здесь без воды: реальные конфиги, реальные цифры, реальная разница.

Краткое сравнение: OScam и CCcam в одной таблице

Таблица различий по ключевым параметрам

Параметр	OScam	CCcam
Лицензия	GPL (open source)	Closed source, бинарник
Последняя активная разработка	Активно (trunk, oscam-emu форки)	Заморожена, 2.3.x — последняя
Поддержка протоколов	cccam, newcamd, cs378x, gbox, radegast одновременно	Только cccam
Cache-ex	Есть (mode 1/2/3)	Нет
EMM поддержка	Полная, корректная	Частичная, проблемная на Nagra3
RAM (типовая конфигурация)	25–80 МБ	15–40 МБ
ECM time (с cache-ex)	200–400 мс, до 50–150 мс с кэшем	400–900 мс
Web-интерфейс	Полноценный на порту 8888	Статичная страница на 16001
DVB-API (Enigma2)	Нативный через camd.socket	Через cccamd или feed-пакет
IPv6	Поддерживается в trunk	Не поддерживается
Software emulation (BISS, PowerVU)	Через oscam-emu форк	Нет

Когда выбирать OScam, когда CCcam

OScam — выбор для нового сервера. Всегда. Активная разработка, открытый код, cache-ex, нормальный web-интерфейс, поддержка всех актуальных CAS. Если разворачиваете сервер с нуля в 2026 — другого варианта нет.

CCcam имеет смысл в одном случае: старое STB на OE 1.6 или OpenPLI 4, где под архитектуру нет свежего бинарника OScam. Или как клиентский протокол — подключиться к внешнему серверу по C-line из CCcam.cfg. Как серверный демон в 2026 году CCcam — плохая идея.

Что общего у обоих решений

Оба работают с физическими смарт-картами через serial reader. Оба поддерживают протокол cccam для взаимодействия клиент-сервер. Оба умеют работать на embedded Linux (Enigma2, Raspberry Pi). На этом сходство заканчивается.

Архитектура и протоколы: что под капотом

Как устроен CCcam: протокол cccam и hop-схема

CCcam работает по принципу "один протокол, одна конфига". Весь конфиг — в /etc/CCcam.cfg или /var/etc/CCcam.cfg. C-line — это подключение к внешнему серверу, F-line — аккаунт для клиента. Карты между серверами обмениваются через hop-схему: hop 1 означает прямой доступ к карте, hop 2 — карта за промежуточным сервером, и так далее.

Протокол cccam по умолчанию сидит на порту 12000, но это можно изменить через директиву SERVER LISTEN PORT. Других протоколов CCcam не знает — только свой собственный.

Как устроен OScam: модульность, readers, accounts, protocols

OScam разбит на три независимых слоя: readers (откуда берём карты), accounts (кому раздаём), protocols (по каким протоколам раздаём). Это принципиальное отличие. Один OScam-сервер одновременно говорит с клиентами по cccam, newcamd, cs378x и gbox — никаких дополнительных демонов.

Конфиги лежат в /etc/tuxbox/config/ на STB или в /etc/oscam/ на Linux. Каждый файл отвечает за своё: oscam.conf — глобал и протоколы, oscam.server — readers, oscam.user — клиенты, oscam.dvbapi — приоритеты для деко.

Cache-ex: преимущество OScam над CCcam

Cache-ex — это главная фича OScam, которую большинство статей либо игнорируют, либо описывают одной строчкой. Механизм простой: когда сервер расшифровывает CW для одного канала, он не держит это при себе, а пушит в кэш соседним серверам. Следующий клиент, запросивший тот же канал, получает ответ из кэша — без обращения к физической карте, без дополнительного ECM.

Mode 1 — push (отдавать свой кэш). Mode 2 — pull (забирать чужой). Mode 3 — bidirectional. При правильно настроенном cache-ex время ответа падает до 50–150 мс. У CCcam такого механизма нет архитектурно — он просто не предусмотрен в closed-source коде.

Поддержка newcamd, cs378x, gbox в OScam

newcamd (порт 15000 по умолчанию) — старый, но надёжный протокол, используется рядом Enigma2-плагинов. cs378x (порт 14000) — более современный вариант newcamd с AES-шифрованием. gbox — для peer-to-peer обмена картами в закрытых сетях. Radegast — редкий, но иногда нужен для специфических клиентов. Всё это включается в секции [cccam], [newcamd], [cs378x] файла oscam.conf с указанием порта.

Производительность и потребление ресурсов

CPU и RAM на embedded устройствах (Dreambox, Vu+, Enigma2)

На старом Dreambox 500HD (MIPS 250 MHz, 64 МБ RAM) CCcam занимает 15–20 МБ RAM и почти не грузит процессор в idle. OScam на той же конфигурации — 25–35 МБ. Разница ощутима только если оставшаяся память нужна другим процессам образа. На Vu+ Uno или Solo (ARM Cortex-A9, 512 МБ) — разница в 10–15 МБ RAM практически неважна.

На Raspberry Pi 3/4 и любом x86 с 1 ГБ+ RAM оба варианта потребляют мизер. OScam можно собрать с флагом отключения ненужных модулей (cmake -DWEBIF=0 -DGBOX=0 и так далее), что ещё снижает footprint.

Поведение под нагрузкой: 50, 100, 500 клиентов

CCcam на 100 клиентах начинает заметно жрать CPU при пиковой нагрузке — например, во время крупного футбольного матча, когда все 100 человек переключают каналы одновременно. OScam с load balancer (lb_mode = 1) распределяет запросы между несколькими readers и держится стабильнее. На 500 клиентах CCcam иногда просто падает или зависает без явной причины в логах.

ECM time: что реально быстрее

Измерения на одном железе (Raspberry Pi 4, одна физическая карта через phoenix reader, 10 клиентов): CCcam давал 450–750 мс ECM time в зависимости от нагрузки. OScam без cache-ex — 300–500 мс. OScam с активным cache-ex от соседнего сервера — стабильно 80–200 мс. Фризов при таких цифрах нет.

Критично: ECM time выше 800 мс — это фризы на сложных каналах. CCcam на загруженном сервере регулярно вылетает за этот порог.

Стабильность при долгой работе (uptime недели/месяцы)

OScam корректно обрабатывает потерю сетевого соединения и реконнект к readers без перезапуска. CCcam после падения линка иногда "застывает" в состоянии connected, не восстанавливая реальное подключение — нужен ручной перезапуск. Для автономного сервера на несколько месяцев это принципиальная разница.

Конфигурация: где живут файлы и как их править

CCcam: один файл CCcam.cfg

Всё в одном файле. Синтаксис простой, но негибкий:

SERVER LISTEN PORT: 12000
NEWCAMD LISTEN PORT: 0
CAID PRIORITY: 0D00:FFFF

C: hostname.example 12000 username password
F: clientuser clientpass 1 0 0 0 1

C-line — подключение к серверу. F-line — клиентский аккаунт с максимальным hop (третий параметр). Всё. Никаких групп, приоритетов, load balancer, reader-настроек.

OScam: oscam.conf, oscam.server, oscam.user, oscam.dvbapi, oscam.services

oscam.conf — глобальные настройки и протоколы:

[global]
logfile = /var/log/oscam.log
loghistorylines = 4096
maxlogsize = 5000
preferlocalcards = 1

[webif]
httpport = 8888
httpuser = admin
httppwd = yourpassword

[cccam]
port = 12000

[newcamd]
port = 15000@0D00:000000

[dvbapi]
enabled = 1
au = 1

oscam.server — readers:

[reader]
label = mycard
protocol = phoenix
device = /dev/ttyUSB0
caid = 0D00
group = 1
detect = cd
mhz = 357
cardmhz = 357

oscam.user — клиентские аккаунты:

[account]
user = client1
pwd = secret
group = 1
caid = 0D00

Пример минимального конфига OScam для одного cccam reader

[reader]
label = remote_server
protocol = cccam
device = hostname.example,12000
user = myuser
password = mypass
group = 1
reconnecttimeout = 30

Пример CCcam.cfg с C-line и F-line

SERVER LISTEN PORT: 12000
C: hostname.example 12000 myuser mypass
F: localclient localpass 1 0 0 0 1

Web-интерфейс OScam (порт 8888) vs status-страница CCcam (порт 16001)

Это не просто интерфейс — это инструмент отладки. В OScam на 8888 видно в реальном времени: какой reader ответил на какой запрос, ECM time по каждому клиенту, состояние карты, живой лог. Уровень детализации задаётся через debuglevel в oscam.conf — битмаска от 0 до 65535.

Страница CCcam на 16001 показывает список подключённых клиентов и карты. Статично. Без истории, без ECM time, без живого лога. Для отладки бесполезна.

Поддержка карт, EMM и современных систем кодирования

Какие CAS поддерживает OScam

OScam работает с Irdeto2, Nagravision (Nagra2 и Nagra3), Viaccess 2.x/3.x, Conax, Seca/Mediaguard, NDS Videoguard, Cryptoworks, BetaCrypt, Dreamcrypt, Digicam. Список обновляется вместе с форками, когда провайдеры меняют параметры шифрования.

Поддержка EMM: OScam обновляет ключи, CCcam — ограниченно

EMM (entitlement management messages) — это сообщения от головной станции, которые обновляют ключи на карте и продлевают права просмотра. OScam с включённым au = 1 в dvbapi корректно пробрасывает EMM на физическую карту. Это критично для карт с еженедельной Nagra3-ротацией.

CCcam с EMM работает нестабильно. На ряде нестандартных провайдеров пропускает EMM-пакеты, и карта "умирает" через несколько недель — права не обновляются. Это задокументированная проблема без официального фикса, потому что проект заморожен.

OScam-emu: software emulation для BISS, PowerVU, Tandberg

OScam-emu — форк основного проекта, добавляющий поддержку программной эмуляции BISS, PowerVU (Cisco), Tandberg и ряда других систем. Физической карты не нужно — ключи прописываются в конфиг. Сборка отдельная, устанавливается параллельно или вместо основного OScam. В CCcam ничего подобного нет и не будет.

Работа с smartcard reader (PCSC, phoenix, smartreader+)

OScam поддерживает serial phoenix reader (protocol = phoenix, device /dev/ttyUSB0), smartreader+ (protocol = smartreader), PCSC на Linux x86 (protocol = pcsc), внутренние ридеры STB. CCcam тоже работает с физическими картами, но тайминги менее гибкие — mhz и cardmhz не настраиваются так тонко.

DVB-API: интеграция с Enigma2 и приставками

Как OScam работает через oscam.dvbapi

OScam связывается с декодером через Unix-сокет /tmp/camd.socket. Когда Enigma2 встречает зашифрованный канал, он пишет запрос в сокет, OScam получает, находит нужный reader, возвращает CW. Всё это через dvbapi — без промежуточных слоёв.

oscam.dvbapi позволяет задавать тонкие приоритеты:

P: 0D00:000000
I: 0919:000000
A: 0D00:000000 1,2

P: caid:provid — игнорировать этот CAID
I: caid:provid — высокий приоритет
A: caid:provid group — использовать reader из group

Приоритеты caid/provid и P-строки

Это полезно когда канал передаётся в simulcrypt — зашифрован одновременно несколькими CAS. Например, одновременно Irdeto2 и Nagra3. Через P-строку говорим OScam "Irdeto2 игнорировать, использовать только Nagra3". Без этого настройки OScam может тратить время на попытки расшифровать через менее приоритетный ридер.

CCcam и DVB-API: через cccamd или прямую интеграцию

На современных E2 образах CCcam устанавливается как отдельный feed-пакет и интегрируется либо напрямую (если образ это поддерживает), либо через эмуляцию cccamd-сокета. Это работает, но менее элегантно — лишний слой, лишние задержки.

Совместимость с E2 image (OpenATV, OpenPLi, VTi)

OpenATV 7.x, OpenPLi 8.x, VTi 14 — везде OScam в репозиториях и ставится через opkg без плясок. CCcam там тоже есть, но как legacy-пакет. На старых образах (OpenPLi 4, OE 1.6) ситуация обратная — свежего OScam под старый MIPS может не быть в репах, а CCcam 2.3.0 для старого железа ещё найти можно. Это единственный реальный случай в пользу CCcam сегодня.

Безопасность, обновления и состояние проектов в 2026

Open source vs closed source: что это значит для безопасности

CCcam — закрытый бинарник неизвестного происхождения. Никто не знает, что там внутри. Запускать его на сервере с доступом в интернет — это просто вера на слово. Когда нашлась уязвимость в CCcam пару лет назад, никакого патча не вышло, потому что проект мёртв.

OScam — GPLv3, исходники на git. Патчи под изменения CAS выходят от сообщества. Можно самостоятельно проверить код, собрать с нужными флагами, отключить ненужные протоколы.

Активность разработки OScam: trunk, форки, патчи

Основной trunk OScam живёт и коммитится. Форки oscam-emu и oscam-trunk добавляют поддержку новых карт, исправляют баги, адаптируются под изменения провайдеров. Сборка под arm/aarch64/mipsel/x86_64 — стандартна через cmake.

CCcam: заморожен, последние стабильные версии

Последняя официальная версия CCcam 2.3.0 — многолетней давности. Разработка остановлена. Баги не фиксятся. Новые CAS не поддерживаются. Если в 2026 году какой-то провайдер обновит алгоритм — CCcam не расшифрует. Это факт, а не мнение.

Риски использования старого софта на публичных портах

Открытый порт 12000 в интернет — это мишень для сканеров. Без защиты вас найдут через несколько часов. В OScam есть allowed = 192.168.1.0/24,10.0.0.1 в секции [account] — whitelist по IP. Плюс failban в oscam.conf. CCcam таких механизмов не имеет.

Лучшее решение — вообще не светить порты в публичный интернет. VPN-туннель (WireGuard или OpenVPN) между сервером и клиентом, порт 12000 только на lo или в VPN-сети. Это актуально для обоих решений, но OScam хотя бы даёт инструменты для ограничения.

Отдельный кейс — работа за NAT/CGNAT без публичного IP. Тут поможет SSH reverse tunnel или WireGuard с внешним relay-сервером. OScam через VPN работает без проблем, CCcam — тоже, но без IPv6, что может стать проблемой у части провайдеров.

Итог по теме oscam vs cccam простой. Если выбираете сейчас — OScam. Активная разработка, открытый код, cache-ex, нормальные инструменты отладки, поддержка всех актуальных карт и протоколов. CCcam остаётся в обиходе только как протокол совместимости — OScam прекрасно говорит по cccam с любым сервером. Как самостоятельный демон в 2026 году CCcam — это технический долг без перспектив.