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 или внешние мониторы.