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

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

Я разберу оба варианта без маркетинга: протоколы, конфиги, реальные цифры ECM, безопасность и где каждый уместен в 2026.

Что такое CCcam и OScam: краткая техническая справка

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

CCcam появился примерно в 2006-2007 году как закрытый бинарник без исходников. Внутри — модифицированный newcamd с проприетарным расширением для share-обмена. Последняя стабильная версия — 2.3.2, выпущена в 2017 году. С тех пор разработка прекратилась.

Бинарник собран под x86 и ARM с достаточно старым libc. На современном Debian 12 он запускается через библиотеки совместимости. На Alpine Linux или musl-окружениях — не запустится вообще. На MIPS-роутерах (Keenetic, TP-Link с OpenWRT) — забудь.

OScam — open-source форк OSCam-emu и его развитие

OScam — это форк MpCS и OSCam, полностью открытый код на C. Компилируется под x86, x86_64, ARMv7, aarch64, MIPS, PowerPC — под что угодно. Активная разработка продолжается: последние коммиты в svn-репозитории датированы 2025-2026 годом.

OScam-emu — отдельный форк с поддержкой эмуляции (PowerVu, TANDBERG, BISS, Constant CW). Он строится из тех же исходников, просто с другим набором флагов компиляции.

История: от MBox и newcs до современных форков

Всё началось с newcs и newcamd — протоколов конца 90-х — начала 2000-х. MBox и затем CCcam добавили share-каскадинг поверх них. Параллельно развивался OSCam как универсальный сервер, поддерживающий несколько протоколов одновременно. Сейчас генеалогия примерно такая: newcamd → CCcam (закрытая ветка) и newcamd → OSCam → OScam (открытая ветка).

Почему оба до сих пор используются в 2026

CCcam жив потому что у людей работающие конфиги и клиенты с CCcam-протоколом. Менять рабочее окружение никто не хочет. OScam набирает долю потому что умеет больше и компилируется на современном железе. Гибридная схема — OScam-сервер с CCcam-клиентами — сейчас, пожалуй, самый распространённый вариант.

Сравнение протоколов: cccam protocol vs newcamd vs cs378x

Протокол CCcam (порт по умолчанию 12000, TCP)

CCcam использует проприетарный TCP-протокол. Клиент подключается на порт 12000 (настраивается через CPORT в CCcam.cfg). Рукопожатие включает SHA1-хеш пары user/pass, после чего сервер отправляет таблицу доступных share. ECM-запросы идут по этому же соединению.

Трафик обфусцирован, но не зашифрован по-настоящему. DPI-системы провайдеров распознают его по характерной сигнатуре рукопожатия. Это проблема.

Newcamd в OScam (порт 15000, TCP, DES-шифрование)

Newcamd — более старый протокол, но с реальным DES-шифрованием трафика. В OScam настраивается через protocol=newcamd в oscam.conf в секции [newcamd]. Ключ шифрования — 14-байтный key. Порт обычно 15000, но можно любой.

Из минусов: DES устарел, 56-битный ключ сегодня не считается надёжным. Но для защиты от провайдерского DPI этого хватает.

cs378x — улучшенный newcamd с AES

cs378x — это расширенный вариант newcamd с AES-128 шифрованием. Поддерживается только OScam. В конфиге: секция [cs378x] с port и key. ECM time через cs378x чуть выше чем через camd35, но безопасность заметно лучше. Если клиент поддерживает — лучше использовать cs378x вместо чистого newcamd.

camd35 UDP — для локальной сети

camd35/cs357x работает по UDP. Быстрее TCP за счёт отсутствия handshake, но без гарантии доставки. Имеет смысл только в локальной сети или VPN с низкими потерями. По интернету — плохая идея. В OScam настраивается через [camd35].

Какой протокол быстрее по ECM time

На одном и том же сервере с одной и той же картой разница реальная. CCcam через свой протокол: ECM time обычно 250-400ms. OScam через cs378x на том же железе: 150-300ms. Разница — в реализации очереди и cacheex. OScam умеет отвечать из кеша на повторные запросы почти мгновенно, CCcam — нет.

При cacheex hit в OScam ECM time падает до 10-50ms. Это ключевое преимущество при большом количестве клиентов с одинаковым контентом.

Конфигурационные файлы: CCcam.cfg vs oscam.conf

Структура CCcam.cfg: C-линии, N-линии, F-линии

CCcam.cfg — один файл, всё в нём. Формат прямолинейный:

• C: — подключение к удалённому CCcam-серверу (клиент)
• N: — подключение через newcamd
• F: — локальный пользователь (с ограничениями по SID, провайдеру)
• B: — блокировка конкретных CAID
• MINIMIZECARDS, CASYSTEM PRIORITY — глобальные настройки

Файл обычно лежит в /etc/CCcam.cfg или /var/etc/CCcam.cfg в зависимости от дистрибутива.

oscam.conf + oscam.server + oscam.user + oscam.dvbapi

OScam разделяет конфиг на несколько файлов, каждый за своё:

• oscam.conf — глобальные настройки, протоколы-серверы (cccam, newcamd, cs378x, camd35)
• oscam.server — ридеры (карты, удалённые серверы)
• oscam.user — аккаунты клиентов
• oscam.dvbapi — настройки для прямого дешифрования на ресивере

Это сложнее для новичка, но куда гибче. Можно выдать одному пользователю доступ к CAID 0x0500 и запретить 0x0100, другому — наоборот. В CCcam такой гранулярности нет.

Пример рабочей C-линии для CCcam

# CCcam.cfg
C: myserver.example.com 12000 myuser mypassword
C: backup.example.com 12000 myuser mypassword {0:0:1}

# Локальный пользователь с ограничением по хопам:
F: localclient password 1 0 0 0 { 0:0:1 }

CASYSTEM PRIORITY: 1802:000000
MINIMIZECARDS: 1
CPORT: 12000

Фигурные скобки после C-линии — опциональный фильтр по CAID:provid:SID. {0:0:1} означает «все CAID, все провайдеры, максимум 1 хоп».

Пример [reader] и [account] секций OScam

# oscam.server
[reader]
label         = server1_cccam
protocol      = cccam
device        = myserver.example.com,12000
user          = myuser
password      = mypassword
group         = 1
cccversion    = 2.3.2
cccmaxhops    = 1
inactivitytimeout = 30

# oscam.user
[account]
user          = localclient
password      = mypassword
group         = 1
au            = server1_cccam
ident         = 1802:000000

# oscam.conf (серверная часть)
[cccam]
port          = 12000

[newcamd]
port          = 15000@1702:000000
key           = 0102030405060708091011121314

[cs378x]
port          = 15001

Где лежат конфиги

Зависит от системы. Типичные пути:

• CCcam: /etc/CCcam.cfg, /var/etc/CCcam.cfg, /usr/keys/CCcam.cfg
• OScam: /etc/oscam/, /etc/tuxbox/config/, /usr/local/etc/oscam/
• На Enigma2 (VU+, Dreambox): /etc/tuxbox/config/oscam/
• Логи OScam: /tmp/oscam.log или через syslog
• Логи CCcam: /tmp/CCcam.log

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

Расход RAM: CCcam ~30-50MB, OScam ~80-200MB

CCcam легковесный — на простом сервере с 10-20 клиентами он ест 30-50MB RSS. OScam с cacheex и несколькими протоколами — 80-200MB. Это важно если ты запускаешь его на роутере с OpenWRT и 128MB RAM. В таком случае OScam нужно компилировать с минимальным набором модулей (--disable-reader-smartreader, отключить неиспользуемые CAID), иначе просто не хватит памяти.

На роутерах с 256MB+ уже нормально. На VPS с 512MB — без проблем оба варианта.

CPU при 100+ клиентах

CCcam при 100 одновременных клиентах грузит один поток CPU — он однопоточный в своей логике обработки ECM. OScam многопоточный: каждый ридер в своём потоке, cacheex отдельно. На современных CPU разницы почти нет, но при спайках — OScam справляется лучше.

Утечки памяти и uptime

Реальная проблема CCcam — через 3-7 суток непрерывной работы начинаются утечки памяти, особенно при большом числе share и активном каскадинге. Workaround, который используют годами: cron-рестарт раз в 2-3 суток.

# crontab -e
0 4 */2 * * /etc/init.d/CCcam restart

Некрасиво, но работает. OScam работает неделями без перезапуска при нормальной нагрузке.

Поведение при потере связи с картой

CCcam при отвале ридера тихо ждёт таймаута, клиенты получают фризы. OScam умеет переключаться на резервный ридер через fallback в oscam.server — переключение происходит за connecttimeout секунд (обычно 5-15). При нескольких картах одного провайдера настраивается балансировка нагрузки через lb_mode.

Логирование и отладка

CCcam пишет в /tmp/CCcam.log минимум: подключения, отключения, иногда ошибки. Уровень не настраивается. OScam — детальное логирование с уровнями 0-255 (loglevel в oscam.conf). На уровне 128 видно каждый ECM-запрос с timing, ридером, CAID. Это делает отладку принципиально другой — в OScam реально понять что происходит.

DVBAPI и работа с ресивером

CCcam: режим клиента через CCcam.providers

CCcam на ресивере работает как CAM-эмулятор через dvbapi. Ресивер (Enigma2) передаёт ECM через сокет, CCcam отвечает CW. Никакой эмуляции — только реальные карты и share. CCcam.providers позволяет фильтровать CAID, но не эмулировать.

OScam dvbapi на Enigma2 (VU+, Dreambox, Octagon)

OScam подключается к dvbapi через /tmp/camd.socket или напрямую через /dev/dvb/adapter0/demux0. В oscam.dvbapi:

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

boxtype меняется в зависимости от железа: dreambox, vuplus, generic. au=1 включает EMM-обновление карты через OScam.

Настройка oscam.dvbapi для скрытия каналов

В oscam.dvbapi можно указать конкретные SID для декодирования или игнорирования:

P: 0:0:0:0:0:0:0:0:0:0
I: 1:2019:7011

Строка I: игнорирует конкретный channel SID. Строка P: добавляет приоритет. Для тонкой настройки при нескольких ридерах это незаменимо.

Работа с PowerVu, Tandberg, BISS через OScam

Это то, чего CCcam не умеет в принципе. OScam-emu поддерживает:

• PowerVu (CAID 0x0E00) — FTA-каналы на американских спутниках
• TANDBERG (CAID 0x1010) — ряд корпоративных каналов
• BISS (режим 1 и E) — трансляции без смарт-карты
• Constant CW — прописанные вручную Control Words

Для Constant CW в oscam.server:

[reader]
label       = biss_channel
protocol    = constcw
device      = /etc/oscam/constant.cw
group       = 1

Эмуляция через oscam-emu (форк)

oscam-emu — отдельная сборка с флагами USE_LIBUSB=1 USE_PCSC=1 HAVE_SSL=1 и эмуляционными модулями. Компилируется из тех же исходников, что основной OScam, но с дополнительными патчами. Если тебе нужна только обычная карта через сеть — базовый OScam достаточен. Если нужен PowerVu или BISS — собирай oscam-emu.

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

Шифрование трафика: CCcam — обфускация, OScam — реальный DES/AES

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

OScam через newcamd использует DES-CBC, через cs378x — AES-128. Распознать это как cardsharing-трафик без дополнительных признаков заметно сложнее. Но и DES — не серебряная пуля.

Туннелирование через SSH/stunnel

Если провайдер агрессивен — оба варианта лучше завернуть в туннель. stunnel проще всего:

# На сервере (/etc/stunnel/stunnel.conf):
[cccam]
accept  = 0.0.0.0:443
connect = 127.0.0.1:12000
cert    = /etc/stunnel/server.pem

# На клиенте:
[cccam-out]
client  = yes
accept  = 127.0.0.1:12000
connect = server.example.com:443

WireGuard — ещё лучше, особенно для группы клиентов. Поднял VPN, все CCcam/OScam соединения идут через него. Провайдер видит зашифрованный UDP-трафик.

Защита от анти-cardsharing мер провайдера

EMM — это обновления ключей карты. Провайдеры периодически делают «кардшаринг-чистку»: шлют специальные EMM, которые убивают карту если она отдаёт больше одного CW одновременно. В OScam EMM forwarding настраивается гранулярно через emmcache и blockemm-* в oscam.server. В CCcam — частично, без полного контроля.

Работа за CGNAT (Carrier-grade NAT) — отдельная боль. Если у тебя нет белого IP и ты за CGNAT — принять входящие соединения невозможно. Решение: VPS с белым IP как ретранслятор, SSH reverse tunnel, или WireGuard между клиентом и сервером.

Частые обрывы (Frequent disconnect) и их причины

Если соединение рвётся каждые несколько минут — причины обычно такие:

• NAT-таймаут на роутере (TCP idle timeout 60-120 секунд на некоторых роутерах). Лечится через keepalive в OScam или keepalive на уровне TCP сокета
• Высокая задержка спутникового интернета (500ms+) — нужно увеличить connecttimeout и ECMtimeout в oscam.server до 3000-5000ms
• CCcam-сервер упал из-за утечки памяти — cron-рестарт
• DPI-блокировка от провайдера — нужен туннель

При спутниковом интернете с RTT 600-800ms ECM timeout по умолчанию (1500ms в CCcam) может не хватать. В OScam: ecmcachesize + увеличенный timeout существенно помогают.

---