CCcam: что это, как работает и как настроить в 2026

Если вы когда-нибудь настраивали спутниковый ресивер и наткнулись на аббревиатуру cccam — вы в правильном месте. Это протокол card sharing, который уже больше десяти лет используется для совместного доступа к зашифрованным телеканалам. Здесь я разберу его техническую архитектуру, конфиги, диагностику и безопасность — без воды и без ссылок на конкретных провайдеров.

Что такое CCcam и как работает протокол card sharing

Card sharing — это схема, при которой одна физическая смарт-карта обслуживает несколько клиентов по сети. Карта вставлена в сервер, клиент посылает ECM-запрос (Entitlement Control Message), сервер расшифровывает его через карту и возвращает клиенту control word. Всё это должно происходить быстро — до 300 мс, иначе картинка начнёт фризить.

Протокол cccam работает поверх TCP, порт по умолчанию — 12000. Handshake начинается с обмена случайными данными (seed), после чего оба узла синхронизируют ключи через DES. Дальше всё общение идёт в зашифрованном виде, хотя сам DES по современным меркам — криптография уровня 1990-х.

История CCcam: от закрытого протокола до де-факто стандарта

CCcam появился где-то в 2006–2007 году. Разработчик — аноним под ником "Fox". Последний официальный релиз — версия 2.3.2 вышла примерно в 2013–2015 году. С тех пор разработка заморожена. Но протокол настолько укоренился в экосистеме спутникового телевидения, что до сих пор является стандартом de facto для peering между серверами.

Почему прижился закрытый бинарь? Потому что в своё время он работал, когда ничего лучше не было. И сейчас большинство провайдеров card sharing гоняют трафик именно по CCcam-протоколу, даже если на серверной стороне у них уже OScam.

Принцип работы: ECM, EMM и control words

Каждый зашифрованный канал DVB использует два ключа — нечётный и чётный CW (control word). Они меняются каждые 10 секунд — именно с этим интервалом и связано большинство проблем с фризами. ECM — это зашифрованный пакет, содержащий новый CW. Без расшифровки (которую делает смарт-карта) вы его не прочитаете.

EMM (Entitlement Management Message) — это обновление прав доступа. Именно через EMM провайдер добавляет или отзывает подписку. Для card sharing важно, чтобы сервер мог получать EMM — это называется AU (Auto Update). Без AU карта постепенно перестаёт работать на некоторых каналах.

Роль DVB-карты, CAM-модуля и ресивера в цепочке

На сервере стоит физическая смарт-карта в ридере (или в CAM-модуле, вставленном в DVB-карту). Карта знает ключи расшифровки — это её главная функция. DVB-карта принимает транспортный поток, извлекает ECM-пакеты и передаёт их на карту. На клиентской стороне ресивер сам ничего не расшифровывает — он просто ждёт CW от сервера и подставляет его в декодер.

Чем CCcam отличается от OScam, MgCamd и NewCamd

OScam — open source, активно разрабатывается, последние коммиты в репозитории датируются 2025–2026 годом. Поддерживает огромное количество протоколов: CCcam, NewCamd, CS378x, gbox, radegast. CCcam же — закрытый бинарь без исходников, и с 2015 года никаких обновлений.

MgCamd — другой клиент, исторически популярный на старых DreamBox-ах. NewCamd — более старый протокол, тоже TCP, но с другим форматом handshake и слабее масштабируется для reshare. На практике сейчас на клиентах всё чаще ставят OScam, а CCcam-протокол используют именно для peering между серверами.

Структура файла CCcam.cfg: разбор всех ключевых директив

Файл конфигурации — сердце всей системы. Неправильная строка в cfg, и вы час будете гадать почему каналы чёрные. Давайте разберём всё по порядку.

Расположение файла на разных прошивках (Enigma2, OpenATV, VTI)

Зависит от образа и версии прошивки. Основные варианты:

• /etc/CCcam.cfg — стандартный путь на большинстве сборок Enigma2
• /usr/keys/CCcam.cfg — OpenATV, VTI и некоторые другие дистрибутивы
• /var/etc/CCcam.cfg — встречается на старых образах DreamBox

После любого изменения файла нужен перезапуск: /etc/init.d/softcam restart. Без перезапуска изменения не применятся — CCcam читает cfg только при старте.

Директивы C: line, N: line, F: line — назначение каждой

C: line — подключение к удалённому CCcam-серверу. Синтаксис:

C: hostname 12000 username password

Четыре поля: хост (или IP), порт, логин, пароль. Регистр имеет значение — пароль Secret и secret это разные вещи. Пробелы в пароле не поддерживаются.

N: line — подключение через протокол NewCamd. Используется реже, для совместимости со старыми серверами на NewCamd. Синтаксис отличается — там нужен 14-байтный DES-ключ.

F: line — это "fake" карта. Директива говорит CCcam притворяться, что он видит карту с определённым CAID. Используется для peering когда нужно анонсировать другим узлам наличие карты, которой физически нет на этом узле.

SERVER LISTEN PORT, WEBINFO LISTEN PORT и DEBUG уровни

Глобальные параметры в начале файла:

SERVER LISTEN PORT : 12000
WEBINFO LISTEN PORT : 16001
DEBUG : 0

DEBUG от 0 до 5. На уровне 0 логируются только критические события. Уровень 3–4 даёт подробный вывод ECM-запросов с CAID, SID и временем ответа. Уровень 5 — абсолютно всё, включая весь трафик. На слабом железе DEBUG 5 заметно грузит CPU.

Параметры SHARE LIMITS, RESHARE и MAXIMUM HOPS

Hop count — количество узлов между клиентом и физической картой. В логах это видно как цифра после CAID. Нулевой hop — карта на этом же сервере. Единица — прямой пир с картой. Двойка и выше — reshare.

MAXIMUM HOPS : 2
RESHARE : 1
SHARE LIMITS : username 5

RESHARE : 1 означает что ваши клиенты могут передавать карту дальше на один уровень. SHARE LIMITS ограничивает количество одновременных ECM-сессий для конкретного пользователя. Это важно — без лимита один клиент может положить сервер потоком запросов.

Пример минимального рабочего cfg для клиента и сервера

Клиентский конфиг (только подключение к серверу):

SERVER LISTEN PORT : 12000
WEBINFO LISTEN PORT : 16001
DEBUG : 0
MAXIMUM HOPS : 2

C: server.example.com 12000 mylogin mypassword

Серверный конфиг (с локальной картой через последовательный ридер):

SERVER LISTEN PORT : 12000
WEBINFO LISTEN PORT : 16001
DEBUG : 1
MAXIMUM HOPS : 1
RESHARE : 0

SERIAL READER : /dev/ttyS0 CARDTYPE CLOCK TIMEOUT

B: mylogin mypassword 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E

B: line — это запись пользователя на сервере. После логина и пароля идут hex-группы, определяющие доступ к CAID.

Установка и настройка CCcam на Enigma2-ресивере

Работал с разными ресиверами — VU+ Duo, Dreambox DM900, Zgemma H9. Процесс везде похожий, но детали расходятся. Особенно в части путей и прав доступа.

Подготовка ресивера: SSH-доступ, права на /usr/bin

Сначала нужен SSH-доступ. Стандартный порт — 22, логин root. На OpenATV в последних версиях пароль по умолчанию пустой или "dreambox" — зависит от сборки. Проверьте сразу же после первого входа и смените.

На OpenATV файловая система смонтирована в read-only. Прежде чем что-то копировать в /usr/bin:

mount -o remount,rw /

После перезагрузки это сбросится, поэтому либо скрипт в автозагрузку, либо используйте пути вроде /usr/keys/, которые живут на writable разделе.

Загрузка бинарника CCcam (выбор версии под архитектуру MIPS/ARM)

Это критически важный момент, который в большинстве мануалов замалчивают. Архитектуры разные:

• Старые DreamBox (DM800, DM7025) — MIPS, нужен CCcam.mipsel
• VU+ Solo 4K, Zgemma H9, DM900 — ARM Cortex-A, нужен CCcam.arm
• Некоторые бюджетные ресиверы — ARM7, отдельный бинарь

Если запустить бинарь не под ту архитектуру — получите тихий сбой без сообщения об ошибке. Проверить архитектуру: cat /proc/cpuinfo | grep cpu model или uname -m.

По версиям: 2.3.0 vs 2.3.2 — на практике разница минимальная. На некоторых ресиверах 2.3.2 ведёт себя нестабильно, 2.3.0 работает чище. Версии 2.1.x не рекомендую — они плохо понимают современные CAID и у них проблемы с handshake с более новыми пирами.

Установка через ipk-пакет vs ручное копирование

Через ipk проще всего — пакетный менеджер сам разложит файлы и создаст init-скрипт:

opkg install CCcam_2.3.0_mipsel.ipk

Ручное копирование даёт больше контроля:

scp CCcam.mipsel [email protected]:/usr/bin/CCcam
ssh [email protected] "chmod 755 /usr/bin/CCcam"

Init-скрипт при ручной установке нужно создать самому или взять готовый — он обычно идёт вместе с бинарём в архиве.

Запуск через init.d-скрипт и автозагрузка

/etc/init.d/softcam start
/etc/init.d/softcam stop
/etc/init.d/softcam restart

Проверить что запустился:

ps | grep CCcam

Должна быть строка с путём к бинарю. Если нет — смотреть лог:

tail -f /tmp/CCcam.log

Проверка работы через telnet и веб-интерфейс на порту 16001

WebInfo доступен по адресу http://IP_ресивера:16001. Там видны все подключённые пиры, CAID которые они отдают, статус карт и ECM-статистика. Это первое место для диагностики — если в WebInfo пир отображается как OFF, на клиенте каналы будут чёрными.

Дефолтный логин в WebInfo на старых сборках — root/root. Меняйте сразу. Это открытый HTTP без шифрования, любой в сети видит всё.

Настройка собственного CCcam-сервера на Linux

Сервер с реальной смарт-картой на Linux — задача посложнее ресивера. Нужен PC/SC-демон, правильные драйверы ридера и корректная конфигурация порта.

Выбор железа: ARM SBC, x86 mini-PC или VPS

Для сервера с реальной картой нужен физический USB-порт или последовательный порт для ридера. VPS с OpenVZ не даст доступа к /dev — там ридер подключить невозможно. На VPS можно только peering (принять карты от другого сервера и раздавать дальше).

Raspberry Pi 4 — нормальный вариант: ARM64, 4GB RAM, есть USB для ридера, потребление 5W. Orange Pi или NanoPi работают аналогично. Для x86 подойдёт любой mini-PC типа Intel NUC.

PC/SC-демон и драйверы для ридеров (phoenix, smartreader+)

apt install pcscd pcsc-tools libpcsclite-dev
systemctl enable pcscd
systemctl start pcscd

Проверить что карта читается:

pcsc_scan

Если карта вставлена в ридер и pcsc_scan её видит — половина работы сделана. Phoenix-ридер через USB обычно определяется автоматически. Smartreader+ требует специфичных драйверов — проверьте lsusb и сравните ID с документацией.

Важный нюанс: карты Conax и Viaccess требуют специфичных параметров SERIAL READER в cfg — скорость порта (стандарт Phoenix — 357 kbps, ISO 7816 — 9600 бод), тип часового сигнала. Irdeto проще в этом плане. Без правильных параметров карта будет "видна" pcscd но CCcam её не поймёт.

Конфигурация смарт-карты в CCcam.cfg (SERIAL READER)

SERIAL READER : /dev/ttyUSB0 PHOENIX CLOCK TIMEOUT 300
SERIAL READER : /dev/ttyUSB0 SMARTREADER CLOCK TIMEOUT 300

Для USB-ридеров путь обычно /dev/ttyUSB0. Для встроенных последовательных портов — /dev/ttyS0. Проверить что устройство есть: ls -la /dev/ttyUSB*.

Открытие порта 12000 в iptables и firewall

iptables -A INPUT -p tcp --dport 12000 -j ACCEPT
iptables -A INPUT -p tcp --dport 16001 -j ACCEPT
iptables-save > /etc/iptables/rules.v4

Если используете ufw:

ufw allow 12000/tcp
ufw allow 16001/tcp

При работе за NAT нужен port forwarding 12000 с внешнего IP роутера на IP сервера. И в cfg пиры должны видеть именно внешний IP — иначе handshake пройдёт, но карты не откроются.

Мониторинг: журнал, watchdog, автоперезапуск через systemd

Systemd unit-файл для автозапуска и мониторинга:

[Unit]
Description=CCcam Card Sharing Server
After=network.target pcscd.service

[Service]
Type=forking
ExecStart=/usr/bin/CCcam
Restart=always
RestartSec=10
User=root

[Install]
WantedBy=multi-user.target

Restart=always + RestartSec=10 — если CCcam упал, через 10 секунд поднимется сам. Это не заменяет нормальный мониторинг, но от случайных крашей спасает.

Диагностика проблем CCcam: что делать когда не работает

Большинство проблем с cccam укладываются в несколько типовых сценариев. Разберём каждый с конкретными командами.

Каналы чёрные: проверка ECM-ответа и control word

Первый шаг — смотреть лог с DEBUG уровнем минимум 3:

tail -f /tmp/CCcam.log | grep -i "ecm\|cw\|error"

Строка нормального ответа выглядит примерно так:

CW from server peer1.example.com for caid:0100 prov:000000 sid:1234 in 187ms

Здесь: caid — идентификатор системы условного доступа, prov — провайдер, sid — ID канала, 187ms — ECM time. Если этой строки нет совсем — сервер не отвечает на ECM. Если есть но каналы чёрные — возможно несоответствие ключей на ресивере.

"no providers" в логе означает: handshake с сервером прошёл успешно, но сервер не анонсировал ни одного CAID. Это либо пустая карта, либо проблема с правами доступа (B: line на сервере не даёт этому пользователю нужные CAID).

"CW not found" — сервер получил ECM-запрос, но не нашёл карту которая его может расшифровать. Канал просто не поддерживается этой картой или провайдером.

Freeze каждые 10 секунд — проблема ECM time или AU

10 секунд — это точно интервал смены control word у провайдера. Если именно через 10 секунд картинка моргает — ECM-обновление либо приходит с опозданием, либо вообще не приходит вовремя.

Что проверить:

• ECM time в логах — должен быть ниже 300ms. Выше 500ms — уже будут проблемы
• Пинг до сервера — если больше 150ms, суммарное время может превысить норму
• AU (auto-update) на сервере — без него карта не получает обновлённые ключи EMM
• Hop count — при hop=3 и больше добавляется задержка на каждом узле

Сервер виден как OFF в WebInfo — сетевые и handshake ошибки

netstat -an | grep 12000

Должны видеть ESTABLISHED соединение. Если нет — либо порт не открыт, либо сервер недоступен. Проверка с клиентской стороны:

telnet server.example.com 12000

Если telnet не подключается — проблема на уровне сети или файрвола. Если подключается но CCcam всё равно показывает OFF — проблема handshake: неправильный логин/пароль или версии протокола несовместимы.

Высокий ECM time (>500ms) — оптимизация маршрута

Можно посмотреть подробно через tcpdump:

tcpdump -i eth0 -n port 12000 -v

Это покажет все пакеты на 12000 порту с временными метками. Видно когда ушёл запрос и когда пришёл ответ.

Оптимизация: выбирать серверы с меньшим пингом, минимизировать hops, убедиться что на сервере нет перегрузки (SHARE LIMITS настроены).

Анализ логов: уровни DEBUG 0-5 и что искать в выводе

Включить подробный лог на время диагностики в CCcam.cfg:

DEBUG : 4

Перезапустить и смотреть:

tail -f /tmp/CCcam.log

При DEBUG 4 в логе видны: все C: line подключения с результатом, каждый ECM-запрос и ответ, CAID-списки от пиров, ошибки handshake. После диагностики верните DEBUG : 0 — иначе лог за день разрастётся до нескольких гигабайт.

CCcam vs OScam: когда что выбирать

Это реальный вопрос без очевидного ответа — зависит от задачи.

Преимущества CCcam: простота peering, лёгкая cfg

CCcam cfg проще читать и редактировать. C: line — одна строка, всё понятно. Для быстрого поднятия клиента на ресивере — это всё ещё быстрее чем разбираться с oscam.server и oscam.conf.

На старых ресиверах с 128MB RAM CCcam потребляет меньше памяти. OScam с многочисленными протоколами и потоками может не влезть. Хотя при большом списке C: line (50+) CCcam тоже начинает жаловаться на нехватку памяти.

Преимущества OScam: open source, больше протоколов, лучше с DVB

OScam поддерживает: CCcam, NewCamd, CS378x, gbox, radegast, camd35, mpcs. CCcam понимает только свой протокол (и в ограниченной мере NewCamd через N: line). Для сервера с реальной картой OScam почти всегда лучший выбор.

Последнее обновление CCcam — примерно 2015 год. OScam получает коммиты регулярно. Новые CAID, новые ридеры, новые алгоритмы — всё это идёт в OScam, не в CCcam.

Совместимость: OScam как клиент к CCcam-серверу

Это распространённая схема. OScam поддерживает CCcam-протокол как клиент — в oscam.server прописывается:

[reader]
label = mypeer
protocol = cccam
device = server.example.com,12000
user = mylogin
password = mypassword
cccversion = 2.3.0
cccmaxhops = 2

Обратное работает хуже — CCcam не умеет подключаться к OScam-серверу через OScam-специфичные протоколы. Только если OScam настроен как CCcam-сервер.

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

Параметр	CCcam 2.3.2	OScam
Протоколы	CCcam, NewCamd	CCcam, NewCamd, CS378x, gbox, radegast
Open Source	Нет	Да
Последнее обновление	~2015	Активно
RAM при idle	~4–8 MB	~10–20 MB
Поддержка DVB-карт	Ограниченная	Широкая
Веб-интерфейс	Порт 16001, базовый	Порт 8888, развитый

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

Это раздел который большинство пропускает. А зря — открытый сервер на 12000 порту живёт в интернете примерно 20 минут до первого сканирования.

Шифрование трафика: встроенный DES vs туннелирование через VPN/SSH

DES в CCcam — это 56-битный ключ. По современным меркам это декоративное шифрование, не реальная защита. Брутфорс 56-битного DES — это задача для FPGA за несколько часов.

Решение: туннелировать через WireGuard или stunnel. WireGuard проще настроить на Linux-сервере, он быстрый и добавляет минимальную задержку. stunnel — если хочется TLS без VPN. Вариант с SSH-туннелем:

ssh -L 12000:localhost:12000 [email protected]

Тогда в cfg на клиенте прописываете C: localhost 12000 login pass — весь трафик идёт через зашифрованный SSH.

Защита WebInfo: смена дефолтного пароля и порта

В CCcam.cfg для WebInfo:

WEBINFO LISTEN PORT : 16001
WEBINFO USERNAME : admin
WEBINFO PASSWORD : YourStrongPassword123

На старых сборках (до 2.2.x) дефолты — root/root. На некоторых сборках WebInfo вообще без аутентификации. Проверьте что у вас — просто откройте браузер на http://IP:16001 без логина.

Смените порт с дефолтного 16001 на что-нибудь нестандартное — сканеры ищут именно 16001.

Ограничение источников через ALLOW и DENY

В CCcam.cfg можно явно указать какие IP могут подключаться:

ALLOW : 192.168.1.0/24
ALLOW : 10.0.0.5
DENY : 0.0.0.0/0

Сначала обрабатываются ALLOW правила, потом DENY. Если IP не попал ни в одно ALLOW — подключение отклоняется. CIDR-нотация работает — можно разрешать целые подсети.

Риски открытия порта 12000 в интернет

Если сервер смотрит наружу, добавьте fail2ban. Пример конфига для /etc/fail2ban/jail.local:

[cccam]
enabled = true
port = 12000
filter = cccam
logpath = /tmp/CCcam.log
maxretry = 5
bantime = 3600
findtime = 600

Нужно ещё создать filter для cccam в /etc/fail2ban/filter.d/cccam.conf — паттерн для неудачных авторизаций зависит от вашего уровня DEBUG и формата лога.

Самый надёжный вариант — не открывать 12000 в публичный интернет вообще. Только через VPN-туннель между доверенными узлами.