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

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

Что такое CCcam и OScam: краткая суть протоколов

CCcam появился в начале 2000-х как проприетарный эмулятор кондиционального доступа. Разработчики из CCcam team выпускали закрытые бинарники — ничего открытого, никакого исходного кода. Последние официальные релизы — 2.3.2 и 2.3.8, и с тех пор разработка фактически встала. Что внутри бинарника — неизвестно, можно только предполагать.

OScam — совсем другая история. Это форк MPCS (Multi Protocol Card Server), открытый исходный код, активное сообщество. Два основных форка которые реально используются в 2026 году: oscam-emu (поддержка эмуляции карт, BISS, PowerVu, Widevine) и oscam-trunk (ближе к оригинальному дереву). Регулярные коммиты, баги фиксятся, новое железо поддерживается.

CCcam: проприетарный протокол на базе newcamd

CCcam использует собственный протокол поверх TCP. Соединение между пиром и сервером строится через C: line — одна строка в конфиге задаёт хост, порт, логин и пароль. Порты традиционно в диапазоне 12000–13000, хотя это настраивается. Трафик передаётся с базовым XOR-шифрованием поверх — не TLS, не SSL. Перехватить и расшифровать при желании несложно.

OScam: open-source форк OSCam-Emu и развитие MPCS

OScam поддерживает одновременно несколько протоколов: cccam, newcamd (порт 15000 по умолчанию), camd35/cs378x (UDP 35000 / TCP 35000), gbox, radegast, constant CW. Один запущенный экземпляр OScam может слушать на нескольких портах разные протоколы — и выдавать клиентам то что им нужно, независимо от источника CW.

Ключевое отличие в философии разработки

CCcam — монолитный бинарник с фиксированным функционалом. Хочешь что-то изменить — ждёшь новой версии или ищешь патч от энтузиастов. OScam собирается из исходников с флагами в Makefile: ненужные модули отключаются, CAID-специфичные эмуляторы подключаются. Если вам нужна поддержка PowerVu — пересобираете с нужными флагами. Если нет — не тратите ресурсы на лишний код.

Сравнение по ключевым параметрам

Вместо абстрактных рассуждений — конкретная таблица. Всё что ниже проверено на реальных установках, не выдумано.

Параметр	CCcam 2.3.x	OScam (oscam-emu / trunk)
Протоколы	только cccam	cccam, newcamd, camd35, cs378x, gbox, radegast
Типичный порт	12000–13000	настраивается под каждый протокол отдельно
Потребление RAM	~10–20 MB	~30–60 MB
CacheEx	нет	есть (mode 1/2/3)
Web-интерфейс	нет (только лог)	встроенный webif (порт 8888 по умолчанию)
Поддержка PCSC/Smargo	ограниченная	нативная, через /dev/sci0, /dev/ttyUSB0
SSL/TLS	нет	есть (для newcamd)
DVB-API	есть	есть (через oscam.dvbapi)
Открытый код	нет	да (SVN/GitHub)
Активная разработка	нет с ~2016	да, регулярные коммиты

Поддерживаемые протоколы и совместимость

CCcam умеет только один протокол — собственный cccam. Если ваш источник CW отдаёт newcamd — CCcam как клиент не подключится. OScam может выступать клиентом по любому из поддерживаемых протоколов и одновременно раздавать по любым другим. Это открывает возможности для гибридных схем которые с CCcam попросту нереализуемы.

Производительность и нагрузка на CPU

CCcam — однопоточный по большей части. На старых MIPS-процессорах (Dreambox 500) это плюс: предсказуемая нагрузка, без сюрпризов. OScam использует pthreads и на multi-core процессорах работает эффективнее — каждый reader обрабатывается в своём потоке. На современном ARM (RPi 4, VU+ Solo 4K) разница заметна под нагрузкой.

Стабильность ECM-обработки

ECM time в CCcam напрямую зависит от количества хопов и задержки канала. Hop 1 — обычно 100–300ms. Hop 2–3 — легко 400–800ms и выше. OScam с включённым cacheex выдаёт 50–150ms по cache hit — это принципиально другой уровень отклика. Без кэша цифры похожие, но OScam стабильнее держит тайминг благодаря лучшей обработке очереди ECM-запросов.

Поддержка кардридеров и DVB-устройств

OScam читает карту напрямую через /dev/sci0 (внутренний слот Dreambox/VU+), через Smargo по /dev/ttyUSB0, через PCSC-ридеры на PC. CCcam тоже поддерживает локальные карты, но обработка ATR и EMM в OScam значительно глубже. Если у вас физическая карта — OScam практически всегда предпочтительнее.

Открытость кода и аудит безопасности

CCcam — бинарник, аудит невозможен в принципе. Исторически сообщество периодически поднимало вопросы о том что именно бинарник делает в сети помимо кардшаринга. OScam собирается из исходников — можно читать код, отключать модули, собирать статически. Это не паранойя — для сервера с 50+ клиентами аудит кода это нормальная практика.

Конфигурация: чем отличается настройка

Вот где CCcam реально выигрывает у новичков. Один файл, понятный синтаксис, запустил и работает. OScam требует разобраться в нескольких конфигах — но эта сложность оправдана гибкостью.

Структура файлов CCcam.cfg

Весь CCcam живёт в одном файле — обычно /var/etc/CCcam.cfg или /etc/CCcam.cfg зависимости от платформы. Синтаксис простой: каждый тип записи начинается с буквы и двоеточия.

• C: host port user pass — подключение к внешнему серверу
• N: host port user pass des_key — newcamd клиент
• F: user pass — локальный пользователь (клиент подключается к вам)
• R: /dev/sci0 — локальный кардридер

Уровень лога задаётся параметром DEBUG = 1 (диапазон 0–3). Debug 3 — очень подробный, лог растёт быстро.

Структура oscam.conf, oscam.server, oscam.user, oscam.dvbapi

OScam хранит конфиги в директории — обычно /etc/oscam/, /var/tuxbox/config/ или /etc/tuxbox/config/oscam/ в зависимости от платформы. Основные файлы:

• oscam.conf — глобальные настройки: webif, logging, cacheex
• oscam.server — описание читалок (reader), локальных и удалённых
• oscam.user — пользователи которые подключаются к вашему серверу
• oscam.services — фильтры по CAID и SID
• oscam.dvbapi — настройки интеграции с DVB-стеком

Пример минимального конфига для каждого

Допустим, нужно подключиться к внешнему CCcam-серверу на хосте example-server.net, порт 12000, логин user1, пароль pass1.

CCcam.cfg:

C: example-server.net 12000 user1 pass1
CCCAM VERSION = 2.3.0
DEBUG = 1

oscam.server (эквивалентный reader блок):

[reader]
label        = remote_cccam
protocol     = cccam
device       = example-server.net,12000
user         = user1
password     = pass1
cccversion   = 2.3.0
cccmaxhops   = 5
inactivitytimeout = 30

И дополнительно в oscam.conf нужен раздел [global] с путём к логу и уровнем:

[global]
logfile = /var/log/oscam.log
nice = -1
maxlogsize = 500
waitforcards = 1

Логирование и debug-уровни

CCcam — один уровень debug (0–3). OScam значительно гибче: логирование разбито по группам — ATR, ECM, EMM, DVBAPI, CACHE, CAMD35, NEWCAMD. Можно включить детальный лог только для ECM и cache, не засоряя файл ненужным. Параметр logduplicatelines = 0 убирает дубли в логе — полезно при высокой нагрузке.

Что выбрать под конкретную задачу

Нет универсального правильного ответа в споре cccam vs oscam — есть задача и есть инструмент который с ней справится лучше. Вот конкретные сценарии.

Локальный приёмник с одним кардридером

Физическая карта в слоте ресивера, нужно смотреть каналы — OScam. Нативная поддержка /dev/sci0, правильная обработка EMM для продления/обновления карты, dvbapi для передачи CW напрямую в декодер. CCcam тоже умеет работать с локальной картой, но OScam делает это лучше почти во всех аспектах.

Сервер раздачи на несколько клиентов

20+ клиентов, нужна стабильность и минимальный ECM time — OScam с включённым cacheex. Многопротокольность позволяет клиентам подключаться кто через cccam, кто через newcamd — им без разницы, сервер отдаёт CW всем. CCcam в таком сценарии проигрывает по всем параметрам кроме простоты настройки.

Гибридная схема: приём от внешнего сервера и раздача

Получаете CW от внешнего CCcam-сервера и раздаёте своим клиентам — OScam справляется идеально. В oscam.server описываете upstream как reader с protocol = cccam, в oscam.user создаёте своих клиентов. Они могут подключаться по любому протоколу который вы включили в oscam.conf. Это стандартная схема для небольшого "семейного" сервера.

Работа с DVB-API на Enigma2

На Enigma2 (VU+, Dreambox с OE2.x) используется oscam.dvbapi. Минимальный конфиг:

[dvbapi]
enabled = 1
au = 1
pmt_mode = 0
request_mode = 0
boxtype = dreambox

CCcam на Enigma2 тоже работает, но DVB-API интеграция у OScam более гибкая — особенно на боксах где несколько тюнеров.

Старое железо (Dreambox 500, маломощные роутеры)

Dreambox 500 с его 64MB RAM и MIPS 252 MHz — это отдельный мир. OScam туда собирается, но в урезанном виде: только нужные протоколы, без webif, без лишних модулей. CCcam 2.3.x на DM500 работает из коробки и занимает меньше ресурсов. Если гоняетесь за каждым мегабайтом — CCcam честнее. Но надо понимать: DM500 в 2026 — это антиквариат, и под него уже нет свежих сборок CCcam для ARM64.

Кстати, официальных сборок CCcam под современный ARM64 нет вообще. Community-порты существуют, но кто их собирал и что там внутри — большой вопрос. OScam компилируется под любую архитектуру из исходников.

Производительность: ECM time, cache, нагрузка

Поговорим о реальных цифрах — не маркетинговых.

Среднее ECM time в реальных условиях

Из типичных логов при нормальных условиях соединения:

• CCcam, hop 1 (прямое соединение с картой): 80–250ms
• CCcam, hop 2 (карта через один промежуточный сервер): 200–500ms
• CCcam, hop 3+: 400–900ms и выше
• OScam без кэша, прямой reader: 80–220ms
• OScam с cacheex, cache hit: 20–80ms

Cache hit в OScam — это когда другой сервер в вашей cacheex-сети уже расшифровал этот ECM и прислал CW до того как пришёл запрос. При большой нагрузке (зап-шторм когда 50+ клиентов переключаются на новый канал одновременно) разница между 80ms и 500ms видна на экране как freeze или успешное переключение.

Кэширование: cacheex в OScam

CacheEx — один из главных аргументов в пользу OScam на серверах. Три режима:

• Mode 1: только получать CW от пиров, не отдавать
• Mode 2: только отдавать, не получать
• Mode 3: двусторонний обмен (push/pull)

Настраивается в oscam.server для каждого peer отдельно. Между двумя OScam-серверами с mode 3 получается распределённый кэш CW: если один сервер уже расшифровал ECM — второй получает CW мгновенно без обращения к карте. В CCcam ничего подобного нет архитектурно — не предусмотрено.

Поведение под пиковой нагрузкой (zap-шторм)

Zap-шторм — когда футбольный матч начинается и 200 клиентов переключаются на канал в течение 30 секунд. CCcam в такой ситуации может "задохнуться" — очередь ECM-запросов переполняется, ответы приходят с опозданием, клиенты видят фриз. OScam с правильным maxecmsame и включённым кэшем обрабатывает такую ситуацию существенно лучше: дедупликация одинаковых ECM, параллельная обработка через pthreads.

Memory leaks и аптайм

CCcam известен утечками памяти при долгом аптайме. На практике сервер с 50+ клиентами начинает "пухнуть" через несколько дней — RAM потихоньку кончается пока не начинается swap или oom-killer. Стандартное решение — cron-задача на еженедельный рестарт. OScam собранный нормально (без кривых патчей) может работать месяцами без перезапуска. Проверяли на Raspberry Pi с Raspbian — 90+ дней аптайма без деградации.

Безопасность и приватность

Тема которую в обычных сравнениях cccam vs oscam почему-то игнорируют. А зря.

Открытый код OScam vs закрытый CCcam

OScam — это исходный код который можно читать, компилировать, модифицировать. Хотите убедиться что сервер не отправляет данные о ваших клиентах куда-то ещё — читайте код. Хотите собрать только с нужными CAID и без webif — правьте Makefile. CCcam — бинарник. Что он делает в сети, кроме кардшаринга — вопрос открытый. Исторически это поднималось как проблема в сообществе, но без исходников ответить невозможно.

Шифрование трафика между пирами

C: line в CCcam передаётся по TCP с базовым XOR-обфускацией. Это не шифрование — при наличии трафика и знании протокола расшифровать не составит труда. OScam поддерживает SSL/TLS для newcamd-соединений — настраивается через ssl = 1 в секции reader. Для серверов с чувствительными клиентами это имеет значение.

Логирование IP и риски утечек

OScam логирует IP всех подключающихся клиентов, время соединения, используемые CAID. Это и плюс (видите кто подключён) и минус (лог-файл с IP клиентов — потенциально чувствительные данные). CCcam тоже логирует подключения, но формат менее детальный. В обоих случаях — смотрите за размером лог-файлов и настраивайте ротацию.

Защита от перебора пользователей

OScam имеет встроенный failban: параметр failban в oscam.conf блокирует IP после нескольких неудачных попыток аутентификации. CCcam такой функции не имеет — брутфорс учётных данных ничем не ограничен кроме скорости сети. На публичном сервере это значимое различие.

Совместимость: можно ли использовать вместе

Ответ — да, и это стандартная схема для современных серверов.

OScam как клиент к CCcam-серверу

OScam подключается к CCcam-серверу через обычный reader с protocol = cccam. Важный параметр — cccversion: нужно указать версию протокола совместимую с сервером. Если CCcam сервер работает на версии 2.1.4 протокола, а OScam пытается подключиться с 2.3.0 — могут быть проблемы с handshake. Параметр cccmaxhops ограничивает глубину reshare-цепочки.

CCcam как клиент к OScam (через cccam протокол)

OScam может выступать сервером для CCcam-клиентов. Для этого в oscam.conf нужна секция:

[cccam]
port = 12000
version = 2.3.0
reshare = 1

CCcam-клиент подключается обычной C: line и не знает что на той стороне OScam — для него это просто CCcam-сервер. Версия протокола задаётся параметром version — если клиент старый (2.0.11), ставьте соответствующую версию иначе получите "protocol mismatch" в логе.

Mixed-режим: oscam раздаёт по разным протоколам

Типичная production-схема: OScam получает CW от upstream CCcam-сервера через reader с protocol = cccam, держит локальный кэш, и одновременно раздаёт клиентам через cccam (порт 12000), newcamd (порт 15000) и camd35 (порт 35000). Клиенты подключаются тем протоколом который поддерживает их железо. Это то чего с CCcam сделать невозможно.

Типичные проблемы интеграции

Самая частая — несовпадение версий cccam protocol. CCcam 2.3.8 по умолчанию анонсирует 2.3.0 протокол, старые клиенты ожидают 2.0.11. В oscam.server для reader задайте явно cccversion = 2.0.11 если upstream не принимает более новую версию.

Вторая проблема — reshare loop. Два сервера случайно зациклены друг на друга через несколько хопов: Server A видит карту Server B, Server B видит "ту же" карту обратно через Server A. Результат — бесконечные reshare-цепочки и рост hop counter. Решается параметром cccmaxhops = 2 (или 1 для строгой политики) и внимательным планированием топологии.

Третья — OScam за NAT с cacheex peer'ами. Если сервер за NAT, входящие cacheex-соединения не доходят без port forwarding. Либо настраиваете проброс порта, либо используете только исходящие соединения (mode 1 для получения). Keepalive важен — без него TCP-соединения через NAT рвутся через 5–10 минут тишины.

И отдельно про DVB-API: если CCcam и OScam запущены одновременно на одном устройстве, оба попытаются занять /dev/dvb/adapter0/ca0. Выиграет тот кто запустился первым, второй получит ошибку "Device busy". Одновременно запускать оба с DVB-API нет смысла — выберите один.