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

Вопрос cccam vs oscam возникает у каждого, кто настраивает cardsharing с нуля или переезжает на новый ресивер. Оба инструмента делают одно и то же — расшифровывают каналы через внешнюю карту или сервер. Но устроены они принципиально по-разному, и в 2026 году разрыв между ними стал ещё заметнее.

Я разберу оба варианта детально — с реальными конфигами, командами и цифрами. Без маркетинга и без выдуманных бенчмарков.

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

Если совсем коротко: CCcam — это закрытый бинарник от анонимного автора, OScam — живой open-source проект с тысячами коммитов. Оба работают как клиент и сервер для распределения ключей расшифровки.

CCcam: проприетарный протокол с закрытым исходным кодом

CCcam появился в районе 2006-2007 года и долгое время был стандартом индустрии. Последняя стабильная версия — 2.3.2. Разработка фактически заморожена: новых релизов не выходит несколько лет, баги не чинятся, новые CAID не добавляются.

Протокол работает поверх TCP, шифрование встроено в бинарник. Исходники недоступны — это и плюс (простота развёртывания) и минус (нельзя ничего проверить или доработать).

OScam: open-source форк OSCam-emu с активной разработкой

OScam вырос из проекта OSCam, который сам по себе создавался как замена CCcam с открытым кодом. OScam-emu — расширенный форк с поддержкой эмуляции дополнительных CAID. Код на C, репозиторий активен, коммиты идут регулярно.

Ключевое отличие: OScam изначально проектировался как универсальная платформа, а не просто реализация одного протокола. Это видно во всём — от архитектуры конфигов до количества поддерживаемых reader'ов.

История появления и текущий статус проектов

CCcam доминировал до примерно 2012-2014 годов, пока сообщество не перешло на OSCam/OScam массово. Сейчас CCcam живёт только за счёт инерции: старые ресиверы, старые образы, старые пиры. На новых установках его выбирают редко.

OScam в 2026 — это де-факто стандарт. Практически все современные образы (OpenATV, OpenPLi, VTi) включают OScam в официальные feed'ы.

Архитектура и поддерживаемые протоколы

Здесь разница кардинальная. CCcam умеет только CCcam-протокол. OScam умеет почти всё.

CCcam: только протокол CCcam (cccam-протокол поверх TCP)

CCcam слушает входящие подключения на порту 12000 по умолчанию. Клиенты подключаются с C-line, сервер раздаёт ключи. Всё. Других вариантов нет — CCcam не умеет работать через newcamd, camd35 или что-то ещё.

Это создаёт проблему обратной совместимости: если сервер раздаёт только newcamd, подключить чистый CCcam-клиент к нему не получится.

OScam: newcamd, cccam, camd35, radegast, gbox, constcw

OScam может одновременно слушать несколько портов с разными протоколами. Типичная конфигурация: newcamd на 15000, cccam на 12001, webif на 8888. Один OScam-сервер принимает клиентов по любому из этих протоколов параллельно.

Как клиент — аналогично. В /etc/oscam/oscam.server можно прописать reader'ов с разными протоколами, и OScam будет опрашивать их все, применяя настроенные приоритеты.

Поддержка readers: phoenix, smargo, internal, SCR3310

OScam читает физические карты через несколько интерфейсов:

• internal — встроенный reader Dreambox, Vu+, Zgemma
• phoenix/smargo — USB-кардридеры через serial
• pcsc — стандартный PC/SC через libpcsclite (SCR3310, ACR38)
• mouse — serial reader в режиме mouse

CCcam тоже работает с internal reader и phoenix, но настройка жёстче зашита в бинарник. Добавить нестандартный reader в CCcam нельзя — в OScam это вопрос одной строки в конфиге.

Работа с CAM-модулями (CI, CI+)

OScam взаимодействует с CI/CI+ модулями через DVBAPI. Параметры в oscam.dvbapi определяют, какой тюнер и какой CAM использовать. CCcam тоже поддерживает CI через DVBAPI, но гибкость настройки ниже.

Конфликт CCcam и OScam на одном DVBAPI — реальная проблема. Если запустить оба, приоритет определяется порядком записей в oscam.dvbapi и тем, кто первым захватил /dev/dvb/adapter0/demux0. Обычно решается выдачей OScam приоритета и использованием CCcam только как дополнительного клиента.

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

Это самое интересное место в сравнении cccam vs oscam, потому что ответ зависит от железа.

Скорость ECM-обработки (миллисекунды на запрос)

На одной и той же физической карте через один и тот же reader:

Протокол	ECM time (типичный)	ECM time (плохой канал)
OScam	200–400 ms	600–900 ms
CCcam	300–600 ms	800–1500 ms

Разница объясняется архитектурой: OScam эффективнее управляет очередью запросов к reader'у. Плюс cache-ex (об этом ниже) резко снижает реальное время при повторных запросах.

Замерить самому просто. Включить в /etc/oscam/oscam.conf секцию [monitor] с aulow=0 и смотреть лог:

tail -f /var/log/oscam/oscam.log | grep "ECM"

Строка будет выглядеть примерно так: 2026/05/19 14:22:31 c (ecm time: 287 ms). Для CCcam логирование беднее — включить через CCcam.cfg параметр LOGFILE и фильтровать по "ECM".

Потребление RAM и CPU на разных платформах (ARM, MIPS, x86)

OScam: 8–15 MB RAM в покое, CCcam: 5–10 MB. Разница небольшая, но на Dreambox 500S с 64 MB RAM это уже имеет значение.

На старых MIPS-ресиверах (до 2012 года) CCcam бывает стабильнее — бинарник оптимизирован под это железо, OScam там может потреблять больше CPU из-за дополнительных фич. На современных ARM (Vu+ Duo4K, Zgemma H9S, любой на bcm7252) OScam выигрывает по всем параметрам.

Поведение при высокой нагрузке (10+ клиентов)

10 одновременных клиентов на OScam — вообще не нагрузка для ARM. Реальное узкое место — скорость физической карты (300–500 ms на ECM) и пропускная способность сети, а не сам OScam.

CCcam при 10+ клиентах начинает давать очереди запросов к карте, ECM time растёт. OScam управляет приоритетами через group и lb_weight — это позволяет настроить кто получает ответ первым.

Если ECM time скачет от 200ms до 2000ms — это почти всегда проблема сети или перегруз карты, не самого протокола. Проверить: ping -i 0.2 -c 100 сервер, смотреть на jitter.

Время переключения каналов (zapping time)

С включённым cache-ex в OScam — zapping time на популярных каналах падает до 100–200ms, потому что CW уже есть в кеше от другого клиента. CCcam каждый раз идёт к карте независимо. На практике разница заметна именно при запинге по HD-пакету, где каналов много и каждый переключает разных людей.

Настройка конфигурационных файлов

Конфигурация — это то, где CCcam проигрывает особенно наглядно.

CCcam.cfg: синтаксис F-line, C-line, N-line

Файл /etc/CCcam.cfg — простой текстовый формат. Минимальная конфигурация клиента:

# Подключение к серверу (C-line)
# C: хост порт пользователь пароль [опции]
C: server.example.com 12000 myuser mypassword

# Локальный аккаунт для раздачи клиентам (F-line)  
# F: пользователь пароль ограничение reshape reshape_cardserial
F: localclient localpass 1 0 0

# N-line — подключение через newcamd к внешнему серверу
# N: хост порт пользователь пароль DES-ключ
N: newcamdserver.com 15000 user2 pass2 01 02 03 04 05 06 07 08 09 10 11 12 13 14

Всё. Больше опций мало — только LOGFILE, LOGLEVEL, IGNORERESHARE. SID-листы задаются в фигурных скобках после пароля в C-line: C: host 12000 user pass no { 0:0:1 }.

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

OScam разбивает конфигурацию на несколько файлов. Стандартное расположение: /etc/oscam/ или /var/keys/ в зависимости от образа. Минимальный рабочий набор:

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

[global]
logfile                       = /var/log/oscam/oscam.log
maxlogsize                    = 500
preferlocalcards              = 1
lb_mode                       = 1

[webif]
httpport                      = 8888
httpuser                      = admin
httppwd                       = сильный_пароль
httpallowed                   = 127.0.0.1,192.168.1.0/24

[dvbapi]
enabled                       = 1
listenport                    = 9000
user                          = dvbapi_user

oscam.server — reader'ы (физические карты и remote серверы):

[reader]
label                         = remote_cccam
protocol                      = cccam
device                        = server.example.com,12000
user                          = myuser
password                      = mypassword
group                         = 1
cccversion                    = 2.3.2
ccckeepalive                  = 1

oscam.user — аккаунты для клиентов:

[account]
user                          = localclient
pwd                           = localpass
group                         = 1
au                            = 1

oscam.dvbapi — привязка к тюнеру:

P: 0500:000000

Пример минимальной рабочей конфигурации для каждого

Для Vu+ Duo4K на OpenATV с OScam — четыре файла выше, плюс перезапуск: systemctl restart oscam или через меню плагинов. Для CCcam — один файл и systemctl restart CCcam.

Расположение файлов: /etc/tuxbox/config/, /var/keys/, /usr/keys/

Расположение зависит от образа:

• OpenATV / OpenPLi: /etc/oscam/
• Старый Gemini (Dreambox): /etc/tuxbox/config/
• Некоторые образы Vu+: /var/keys/ или /usr/keys/
• CCcam везде читает /etc/CCcam.cfg как первичный путь

Если OScam не стартует — первое что проверить: права на директорию конфигов (chown -R root:root /etc/oscam && chmod 644 /etc/oscam/*).

Веб-интерфейс и мониторинг

Это одно из самых ощутимых преимуществ OScam для тех, кто реально следит за своей системой.

OScam WebIF: статистика, лог, управление readers в реальном времени

WebIF открывается на http://ресивер:8888. Там есть: статус каждого reader (онлайн/оффлайн, ECM time, количество запросов), список подключённых клиентов с трафиком, live log с фильтрами, статистика по CAID и SID, возможность перезапустить отдельный reader без перезапуска всего OScam.

Это полноценный dashboard. Я не знаю другого инструмента в этой нише, который даёт такую видимость в браузере без дополнительного ПО.

CCcam: webinfo на порту 16001 — базовая информация

CCcam webinfo (http://ресивер:16001) показывает: список C-line с состоянием, активные пиры, версию. Это текстовая страница, почти без форматирования. Диагностировать по ней серьёзные проблемы неудобно — нет графиков, нет истории, нет детального лога.

Просмотр ECM/EMM трафика и диагностика

В OScam WebIF есть раздел с EMM/ECM трафиком в реальном времени — видно какой CAID, какой провайдер, сколько времени занял ответ. Для диагностики "почему этот канал не работает" — бесценно.

В CCcam такого нет. Придётся парсить лог вручную.

Live log: tail -f oscam.log vs CCcam.log

OScam пишет подробный структурированный лог. С уровнем DEBUG=4 в oscam.conf видно каждый ECM-запрос с временем, CAID, SID и reader'ом, который ответил. CCcam логирует меньше деталей, формат менее предсказуемый.

# OScam: детальный лог в реальном времени
tail -f /var/log/oscam/oscam.log | grep -E "ECM|reader|client"

# CCcam: базовый лог  
tail -f /var/log/CCcam.log

Включить DEBUG в OScam: в oscam.conf добавить debug = 64 в секцию [global]. На продакшне лучше держать 0 или 4 — DEBUG=64 генерирует гигабайты логов за день.

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

Тема, которую обычно игнорируют — а зря.

Закрытый код CCcam: что внутри бинарника неизвестно

CCcam — бинарник без исходников. Что он делает кроме cardsharing — проверить невозможно. Реверс-инжиниринг старых версий находил в нём сетевую активность сверх ожидаемого. Это не значит что он обязательно вредоносный, но проверить нельзя. В 2026 году запускать закрытый бинарник из интернета на домашнем ресивере — это осознанный риск.

Открытый код OScam: возможность аудита

OScam лежит на GitLab и SVN streamboard. Код открыт, история коммитов публична. Любой может проверить что делает конкретная функция. На практике это означает: известные уязвимости быстро закрываются, и нет скрытой функциональности.

Шифрование трафика между peer'ами (DES, AES)

CCcam шифрует трафик своим алгоритмом на основе DES — детали недокументированы. OScam в режиме newcamd использует тройной DES для шифрования сессии. Ни тот ни другой не предоставляют современного end-to-end шифрования уровня TLS 1.3.

Если нужна реальная защита трафика — поднять WireGuard или OpenVPN тоннель между клиентом и сервером и работать внутри него. Тогда сам протокол cardsharing-шифрования становится вторичным.

Защита webif: HTTPS, IP whitelist, httpallowed

WebIF OScam по умолчанию открыт для всех. Обязательно ограничить:

[webif]
httpport                      = 8888
httpuser                      = admin
httppwd                       = минимум-16-символов-случайный
httpallowed                   = 127.0.0.1,192.168.1.0/24
httpdyndns                    = 0

Без httpallowed webif доступен из интернета если порт проброшен. Сканеры Shodan регулярно находят открытые OScam-инстансы. CCcam webinfo на 16001 — аналогичная ситуация, защита только через фаерволл.

Для HTTPS в OScam: параметр httpsport + httpscert с путём к PEM-сертификату. Самоподписанный работает нормально для домашнего использования.

Что выбрать: критерии решения

Когда обсуждают cccam vs oscam, часто ищут универсальный ответ. Его нет — зависит от ситуации. Но в 2026 году выбор в большинстве случаев очевиден.

Если ресивер старый (MIPS, до 2014) — рассмотрите CCcam

Dreambox 500S, Dreambox 800 на MIPS-процессоре, старые Clones с ядром Linux 2.6 — для них OScam может не собраться из-за несовместимости тулчейна. Или соберётся, но будет потреблять слишком много CPU. На таком железе CCcam 2.3.2 работает предсказуемо.

Проверить архитектуру: uname -m. Если выдаёт mips — искать готовый OScam-бинарник под эту платформу или оставить CCcam.

Если нужны несколько протоколов одновременно — OScam

Сервер раздаёт newcamd, а у вас CCcam-клиент? OScam решает это одной строкой в oscam.server. Нужно раздавать своим клиентам и по cccam и по newcamd одновременно? OScam, однозначно.

Если важна диагностика и логирование — OScam

Если вы администрируете сервер с несколькими клиентами и хотите понимать что происходит — OScam WebIF не имеет альтернатив. CCcam для такого сценария откровенно слаб.

Если нужна работа с физическими картами через PCSC — OScam

Только OScam. CCcam не умеет работать с PC/SC через libpcsclite. Если у вас SCR3310 или ACR38 подключён к x86-серверу — выбор очевиден.

И ещё один момент: если вы подключаетесь к серверу, который работает на OScam с cache-ex — как клиент вы от этого не выигрываете напрямую. Но если у вас тоже OScam и вы участвуете в cache-ex пуле — zapping time падает для всех участников. Это кооперативная оптимизация, которой в cccam vs oscam сравнениях почему-то не уделяют внимания.