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 создаёт дополнительные проблемы с пробросом портов и добавляет задержку.
Practical checklist for smooth viewing
Even the best CCCam or OSCam line needs two or three simple preparations. Update your receiver firmware, reset the ECM cache once a week and keep 15–20% free space on the USB stick or internal flash so that the reader can store keys without delays.
When tuning a dish, aim for MER/BER reserve: a two‑degree offset or a loose F‑connector often causes the “freezing” that users blame on cardsharing. Keep a short patch cord to test alternative routers, and save two profiles in OSCam — one for TCP, one for UDP — so you can switch instantly if your ISP starts filtering a protocol.
Utgard.tv monitors each hub 24/7, but you can speed up diagnostics by keeping a short log of your receiver actions. Note the time when you changed the channel, which CAID was active and whether you used Wi‑Fi or Ethernet. This tiny “journal” helps engineers reproduce your environment in the lab and return with a solution in minutes instead of hours.
- Keep two line slots enabled: if the first server hits a maintenance window, the second one instantly takes over without re-entering credentials.
- Run a monthly speed and latency test. Stable 1–2 Mbps with ping <80 ms is enough for SD/HD, but if jitter exceeds 20 ms, switch the router to wired mode.
- Save the Utgard.tv status page and Telegram bot @utgard_tv_bot to bookmarks — they publish maintenance notices before SEMrush or uptime monitors raise alerts.