CCcam сервер: настройка, конфиг и работа протокола

Если вы работаете с DVB-оборудованием и условным доступом, то cccam server — это, скорее всего, первое, с чем вы столкнулись. Протокол старый, местами грубоватый, но до сих пор рабочий. В этой статье — техническое устройство изнутри, реальные конфиги, диагностика и честный взгляд на то, почему сам бинарник CCcam давно пора считать историей.

Что такое CCcam сервер и как работает протокол

CCcam — это протокол card sharing, позволяющий нескольким клиентам использовать одну физическую смарт-карту через сеть. Сервер держит карту в ридере, клиент посылает запрос, сервер возвращает ключ дешифрования. Всё это происходит по TCP быстрее, чем смена control word на транспондере.

Архитектура клиент-сервер в card sharing

Схема простая: ресивер клиента получает зашифрованный поток с транспондера. Для расшифровки нужен control word (CW), который извлекается из ECM-пакета с помощью ключа, хранящегося на смарт-карте. Если карты нет локально — клиент отправляет ECM на удалённый cccam server по TCP.

Сервер принимает ECM, передаёт его на физический ридер (PC/SC, Smargo, Phoenix), карта обрабатывает запрос и возвращает CW. Сервер пересылает CW обратно клиенту. Всё это должно произойти за 200-800 ms — иначе будут фризы.

Обмен ECM/EMM и роль DCW

ECM (Entitlement Control Message) — это зашифрованный пакет в MPEG-потоке, содержащий control word. EMM (Entitlement Management Message) — это служебные сообщения провайдера для управления подписками на карте. DCW (Decrypted Control Word) — это и есть результат: 16 байт, которые DVB-чип использует для расшифровки видео.

CCcam передаёт только ECM→CW. EMM-обработку нативный CCcam делает плохо — это одна из главных причин, почему карты со временем «устают» без нормального AU (Automatic Updating).

Чем CCcam отличается от OScam и Newcamd

Newcamd — ещё более старый протокол, использует UDP и проще по структуре. CCcam работает поверх TCP, поддерживает reshare (цепочку серверов) и имеет собственный бинарный формат пакетов. OScam — это уже не протокол, а программа, которая умеет говорить на языке CCcam, Newcamd, Radegast и ещё десятке других одновременно.

На практике: если у вас есть C-линия (строка подключения к cccam server), она будет работать как с нативным CCcam, так и с OScam, настроенным на приём cccam-клиентов.

Reshare, hop и глубина пересылки

Hop — это количество промежуточных серверов между вами и физической картой. Hop 0 — карта прямо в вашем ридере. Hop 1 — карта на сервере провайдера, вы подключаетесь напрямую. Hop 2 — кто-то взял C-линию от hop 1 и перепродаёт вам дальше.

С каждым hop прибавляется задержка и нестабильность. Hop 3+ — это почти всегда проблемы с ECM time и фризами в прайм-тайм. Reshare определяет, разрешено ли вам пересылать полученный CW дальше своим клиентам.

Установка и базовая настройка CCcam сервера на Linux

Прежде чем начинать — важное предупреждение. Бинарник CCcam 32-битный и не обновлялся примерно с 2011 года. На современных дистрибутивах без ia32-libs/multilib он просто не запустится. Если вы ставите новый сервер — лучше сразу смотрите в сторону OScam. Но если у вас уже есть рабочая Enigma2 приставка или старый Debian — CCcam вполне живёт.

Системные требования и совместимость (Debian, Ubuntu, Enigma2)

Нативно CCcam работает на Enigma2 (Dreambox, VU+, GigaBlue и прочие), где ARM-архитектура и 32-bit окружение — норма. На x86_64 Ubuntu 22.04+ нужны мультиарх-библиотеки:

dpkg --add-architecture i386
apt update
apt install libc6:i386 libstdc++6:i386

На Debian 11 и старше это работает нормально. На Ubuntu 24.04 с её aggressively-minimal libc уже могут быть сюрпризы.

Установка бинарника CCcam в /usr/bin/

Получив бинарник CCcam (обычно это файл с именем CCcam.2.3.0 или аналогичным), установка выглядит так:

cp CCcam.2.3.0 /usr/bin/CCcam
chmod +x /usr/bin/CCcam

Конфигурационный файл на Linux-десктопе обычно ищется в /etc/CCcam.cfg, но на Enigma2-приставках стандартный путь — /var/etc/CCcam.cfg. Проверить, где именно смотрит ваша сборка, можно через strings /usr/bin/CCcam | grep CCcam.cfg.

Структура конфигурации /var/etc/CCcam.cfg

Файл текстовый, без XML и без YAML. Каждая директива — отдельная строка. Комментарии через #. Порядок строк не важен, регистр — важен.

Запуск как systemd-сервис и автозапуск

На современных Debian/Ubuntu создаём юнит-файл /etc/systemd/system/cccam.service:

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

[Service]
Type=forking
ExecStart=/usr/bin/CCcam
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Затем:

systemctl daemon-reload
systemctl enable cccam
systemctl start cccam

На Enigma2 всё проще — достаточно положить скрипт в /etc/init.d/ и добавить симлинк через update-rc.d.

Логирование в /tmp/CCcam.log и уровни debug

По умолчанию CCcam пишет лог в /tmp/CCcam.log. Для запуска с расширенным выводом:

CCcam -d

Это даёт verbose-режим прямо в stdout. Удобно при первичной настройке. В production так не держите — лог растёт быстро. Для анализа в реальном времени удобнее tail -f /tmp/CCcam.log | grep ECM.

Конфигурация CCcam.cfg: F-линии, C-линии и параметры сервера

Вот здесь большинство гайдов дают кашу. Давайте разберём построчно.

Синтаксис F-линии для пользователей (F: user pass hops reshare)

F-линия описывает аккаунт, который вы выдаёте своим клиентам:

F: username password 1 0

Поля по порядку:

  • username — логин клиента
  • password — пароль
  • 1 — максимальный hop, который клиент видит (1 = только локальные карты)
  • 0 — разрешение reshare: 0 = запрещено, 1 = разрешено с тем же hop

Если хотите дать клиенту reshare с ограничением до 1 hop:

F: username password 1 1 { 0:0:2 }

Фигурные скобки — это фильтры по CAID:ProvID:serviceID. 0:0:2 означает «разрешить reshare только для CAID 0, любой ProvID, maxhops 2».

Синтаксис C-линии для подключения клиента (C: host port user pass)

C-линия — это то, что вам даёт провайдер для подключения вашего CCcam к их cccam server:

C: server.example.com 12000 mylogin mypassword

Можно добавить опциональный пятый параметр — признак шифрования (обычно no/yes, но реализация зависит от версии). В большинстве случаев четырёх полей достаточно.

Серверные параметры: SERVER LISTEN PORT, WAIT TIME, DISABLE EMM

SERVER LISTEN PORT: 12000
WAIT TIME: 500
DISABLE EMM: yes
IGNORE RESHARE: no
SERIAL DEVICE: /dev/ttyUSB0

Порт 12000 — дефолтный. Для безопасности стоит поменять на нестандартный (например, 15847). WAIT TIME — таймаут ожидания CW от ридера в миллисекундах. При значениях выше 800 начинаются фризы. DISABLE EMM: yes имеет смысл, если вы работаете только как клиент и не хотите нагружать физическую карту EMM-трафиком.

Настройка ридеров: SERIAL READER, NEWCAMD CLIENT, RADEGAST

Если у вас физический ридер:

SERIAL DEVICE: /dev/ttyUSB0 SMARGO
SERIAL DEVICE: /dev/ttyS0 PHOENIX

Smargo — это USB-ридер с фиксированной скоростью. Phoenix — более гибкий, с поддержкой нестандартных скоростей карт. Если ридер не определяется — проверьте dmesg | grep tty сразу после подключения.

Подключение к Newcamd-серверу как клиент:

N: host.example.com 15000 user pass 0102030405060708091011121314

Последнее поле — DES-ключ (14 байт в hex). Это не полноценное шифрование с точки зрения современной безопасности, но так устроен протокол Newcamd.

Шифрование трафика и DES-ключи (если применимо)

CCcam-протокол использует собственное простое шифрование на основе XOR с начальным обменом ключами. Это не TLS и не AES. Трафик между клиентом и сервером теоретически может быть расшифрован при наличии начального handshake. На практике — используйте VPN или SSH-туннель, если это вас беспокоит. Голый CCcam-порт в интернете без дополнительной защиты — плохая идея.

Диагностика и устранение проблем с CCcam сервером

Это раздел, который реально решает проблемы. Большинство сайтов пишут «проверьте C-линию» — и всё. Этого недостаточно.

ECM time высокий: причины и нормальные значения (<400 ms)

Нормы такие: меньше 400 ms — хорошо, 400-700 ms — терпимо при нечастой смене CW, 700-1000 ms — фризы в прайм-тайм, больше 1000 ms — каналы будут выдавать чёрный экран регулярно. Control word на большинстве провайдеров меняется каждые 10 секунд, и новый CW должен прийти до этого момента.

Смотреть ECM time можно через веб-интерфейс CCcam на порту 16001 (http://адрес-приставки:16001) или через лог:

grep "ECM" /tmp/CCcam.log | tail -50

Если высокий ECM только на конкретных каналах — значит этот CAID идёт через медленный hop. Проверьте, на каком hop находится нужная карта.

Freezes и черный экран: проверка C-линий через cccam info

Первый шаг — открыть веб-интерфейс и проверить статус C-линий. Зелёная линия — подключена, красная — нет. Если все линии зелёные, но каналы не идут — проблема в CAID или PMT.

Редкий, но реальный случай: сервер работает, ECM приходит, CW возвращается, но картинка чёрная. Это чаще всего означает, что ресивер неправильно применяет CW — PMT-парсер видит неверный ECM-PID. Проверьте версию программного обеспечения ресивера.

Connection refused / timeout — анализ tcpdump и iptables

Базовая проверка доступности порта:

telnet адрес-сервера 12000

Если «Connection refused» — сервис не слушает порт. Если timeout — firewall. Проверяем:

tcpdump -i any port 12000 -n

Если пакеты приходят, но ответа нет — CCcam запущен, но не отвечает. Смотрим лог и статус процесса:

ps aux | grep CCcam
iptables -L -n | grep 12000

Карта в локальном ридере не читается (PPS, ATR)

ATR (Answer to Reset) — это первый ответ карты при подключении. Если CCcam не видит карту, смотрим лог на строки ATR и PPS. PPS (Protocol and Parameter Selection) — это согласование скорости обмена. Некоторые карты требуют нестандартную скорость, и если ридер её не поддерживает — карта молчит.

В таких случаях помогает переключение ридера на режим Phoenix с нестандартной скоростью, или замена на Smargo, который фиксирован на 357600 baud и более совместим с проблемными картами.

Падение CCcam процесса и анализ core dump

CCcam иногда падает без предупреждения, особенно на нестандартных ядрах. Включить core dump:

ulimit -c unlimited
CCcam &

Файл core появится в текущей директории. Анализ через gdb /usr/bin/CCcam core даст stacktrace. На практике это нужно редко — чаще достаточно автоматического рестарта через systemd с Restart=on-failure.

OScam как современная альтернатива CCcam

Скажу прямо: если вы ставите cccam server с нуля в 2026 году — ставьте OScam. Нативный CCcam бинарник — это археология.

Почему разработка CCcam остановилась и проект заброшен

Последние значимые релизы CCcam вышли около 2011-2012 года. Исходного кода нет — это проприетарный бинарник. Никакого актуального мейнтейнера, никаких патчей безопасности. На 64-bit системах без ia32-libs просто не работает. На современных ядрах Linux некоторые вещи ведут себя непредсказуемо.

OScam (Open Source Conditional Access Module) активно разрабатывается, последние ревизии — r11730+, исходник открыт, собирается под любую архитектуру.

Совместимость OScam с CCcam-протоколом (cccam в oscam.server)

OScam умеет подключаться к cccam server как клиент. В файле /etc/oscam/oscam.server добавляем секцию:

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

cccversion влияет на то, как сервер воспринимает ваш клиент. Версия 2.3.0 — наиболее совместимая. Некоторые серверы реагируют на другие версии иначе — экспериментируйте, если есть проблемы с подключением.

Преимущества OScam: webif, stapler, EMM-кэш

Веб-интерфейс OScam на порту 8888 даёт куда больше информации, чем CCcam web на 16001: реальные ECM-времена по каждому ридеру, статистика hit/miss, очередь запросов, статус EMM. EMM-кэш позволяет не гонять одинаковые запросы на карту снова и снова, что снижает нагрузку и задержки.

Stapler — механизм балансировки нагрузки между несколькими ридерами с одинаковым CAID. Если у вас несколько C-линий на один и тот же пакет, OScam сам распределит запросы и переключится на резерв при падении основной.

Миграция конфигов: CCcam.cfg → oscam.server + oscam.user

Каждая C-линия из CCcam.cfg превращается в секцию [reader] в /etc/oscam/oscam.server. Каждая F-линия — в секцию [account] в /etc/oscam/oscam.user:

# oscam.user
[account]
user         = username
pwd          = password
group        = 1
au           = 1
cccmaxhops   = 1

Параметры SERVER LISTEN PORT из CCcam.cfg переходят в /etc/oscam/oscam.conf:

[cccam]
port         = 12000

Критерии выбора провайдера CCcam сервера

Рынок card sharing заполнен предложениями. Большинство из них — либо перекупы с hop 3+, либо скам. Вот что реально имеет значение.

Hop 1 как обязательное требование к качеству

Hop 1 — это не маркетинг, это техническое требование. На hop 1 ваш ECM идёт напрямую на физическую карту, без промежуточных серверов. На hop 2 и выше каждый посредник добавляет 50-200 ms задержки и точку отказа. Если провайдер не готов подтвердить hop 1 — это красный флаг.

Проверить реально: подключитесь, откройте веб-интерфейс CCcam или OScam и посмотрите, какой hop показывается для карт, с которых идут ваши каналы.

Стабильность аптайма и SLA

«99.9% uptime» без технических деталей — ничего не значит. Интересуют конкретные вещи: есть ли мониторинг с историей, что происходит при падении сервера (автоматический рестарт, failover), какое максимальное окно обслуживания. Хороший провайдер даёт тестовый период — хотя бы 24-48 часов, чтобы оценить реальное поведение в прайм-тайм.

Скорость ECM и географическая близость серверов

Физическое расстояние влияет на задержку. Сервер в той же стране даст меньше RTT, чем сервер через Атлантику. Но важнее — качество канала. Сервер в соседней стране с хорошим датацентром и стабильным BGP даст меньше ECM time, чем локальный сервер на VPS с перегруженным процессором.

Проверяйте ECM time в разное время суток. Прайм-тайм (19:00-23:00 по местному времени) — настоящий тест нагрузки.

Поддержка нужных CAID и пакетов

CAID (Conditional Access Identifier) — это числовой идентификатор системы условного доступа провайдера. Перед покупкой уточните конкретные CAID, которые вам нужны, и убедитесь, что провайдер их поддерживает не «теоретически», а реально — с логами и тестовым доступом.

Пакеты меняются, карты обновляются, некоторые CAID могут работать нестабильно в конкретный момент. Честный провайдер об этом предупреждает.

Резервные линии (backup C-lines) и failover

Иметь одну C-линию — значит иметь единую точку отказа. Нормальный сервис даёт как минимум два сервера — основной и резервный. В OScam это настраивается через несколько секций [reader] с одинаковым group и разными device: при недоступности первого, запросы автоматически уходят на второй.

Спросите у провайдера: есть ли резервный адрес, на разных ли датацентрах они стоят. Два сервера в одном дата-центре — не настоящий failover.

Какой порт по умолчанию использует CCcam сервер?

Порт 12000 — дефолтный для клиентских подключений через C-линии. Порт 16001 — веб-интерфейс CCcam. Оба стоит менять: 12000 активно сканируется ботами, стандартный порт привлекает нежелательное внимание. В CCcam.cfg параметр SERVER LISTEN PORT, в OScam — секция [cccam] с параметром port.

Где находится конфигурационный файл CCcam?

На Enigma2-приставках (Dreambox, VU+, GigaBlue) — /var/etc/CCcam.cfg. На обычных Linux-системах — /etc/CCcam.cfg. Точный путь можно узнать через strings /usr/bin/CCcam | grep cfg. Лог всегда в /tmp/CCcam.log — это жёстко зашито в бинарник.

Чем отличается F-линия от C-линии в CCcam.cfg?

F-линия (F: user pass hops reshare) — это аккаунт, который ваш сервер выдаёт клиентам. Вы описываете, кто может к вам подключиться. C-линия (C: host port user pass) — это адрес удалённого cccam server, к которому ваш CCcam подключается как клиент. F — «from you», C — «connect to».

Что означает hop 1, hop 2 и hop 3?

Hop 0 — физическая карта прямо в вашем ридере. Hop 1 — карта на сервере провайдера, прямое подключение без посредников. Hop 2 — кто-то купил доступ к hop 1 и перепродаёт вам. Hop 3 — ещё один посредник в цепочке. Каждый дополнительный hop прибавляет задержку и нестабильность. Hop 3+ — почти гарантированные проблемы в прайм-тайм.

Какой нормальный ECM time для стабильного просмотра?

Меньше 400 ms — отлично, смотрится без проблем. 400-700 ms — приемлемо при обычном режиме просмотра. 700-1000 ms — фризы при активной смене каналов и в прайм-тайм. Больше 1000 ms — постоянный чёрный экран. Control word меняется обычно каждые 10 секунд, и новый CW должен приходить с запасом по времени.

Можно ли использовать CCcam сервер на современных 64-bit дистрибутивах?

Технически да, но с костылями. Бинарник CCcam 32-битный, поэтому на x86_64 нужны ia32-libs или мультиарх-пакеты (dpkg --add-architecture i386). На Ubuntu 24.04 это работает нестабильно. Нормальное решение — OScam: нативно 64-bit, активно поддерживается, полностью понимает CCcam-протокол.

Безопасно ли держать CCcam-порт открытым в интернет?

Нет. Порт 12000 регулярно сканируется, протокол CCcam не имеет надёжного шифрования. Минимальные меры: нестандартный порт, белый список IP через iptables, сложные пароли в F-линиях. Лучшее решение — VPN или SSH-туннель между клиентом и сервером. Если сервер дома — двойной NAT создаёт дополнительные проблемы с пробросом портов и добавляет задержку.

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

Даже самая стабильная линия CCCam или OSCam требует пары простых подготовительных шагов. Обновляйте прошивку ресивера, раз в неделю очищайте ECM‑кеш и держите 15–20% свободного места на USB‑накопителе или во встроенной памяти, чтобы кардридер записывал ключи без задержек.

При настройке антенны оставляйте запас по MER/BER: смещение на два градуса или ослабленный F‑коннектор чаще становится причиной “фризов”, чем сам кардшаринг. Держите под рукой короткий патч‑корд для проверки другого роутера и сохраните два профиля в OSCam — под TCP и под UDP — чтобы мгновенно переключиться, если провайдер начнёт фильтровать протокол.

Utgard.tv следит за каждым хабом 24/7, однако вы можете ускорить диагностику, если будете вести небольшой журнал действий. Записывайте время переключения канала, активный CAID и то, использовали ли вы Wi‑Fi или Ethernet. Такой мини‑отчёт позволит инженерам воспроизвести вашу конфигурацию в лаборатории и предложить решение не за часы, а за минуты.

  • Держите активными две линии: если первый сервер уходит на обслуживание, второй тут же подхватывает поток без повторного ввода логина.
  • Раз в месяц делайте замер скорости и задержек. Стабильных 1–2 Мбит/с при пинге до 80 мс достаточно для SD/HD, но если джиттер превышает 20 мс — переведите роутер на провод.
  • Сохраните в закладки страницу статуса Utgard.tv и Telegram‑бота @utgard_tv_bot — там появляются уведомления о работах раньше, чем успеют среагировать SEMrush или внешние мониторы.