Cardsharing IPTV: настройка CCcam и OScam с нуля

Если вы уже разобрались с азами спутникового или кабельного приёма и теперь хотите понять, как именно работает cardsharing iptv в связке с эмуляторами — эта статья для вас. Никакой теории ради теории: только конфиги, пути к файлам, реальные команды и алгоритм диагностики, когда что-то идёт не так.

Что такое cardsharing и при чём здесь IPTV

Две разные вещи, которые часто путают. Cardsharing — это технология распределения ключей дешифрования по сети. IPTV — это способ доставки самого видеопотока. Одно без другого работает, но вместе они дают интересные комбинации.

Принцип работы: control word и обмен ключами

Зашифрованный поток DVB или IPTV-стрим не несёт ключи открытым текстом. Каждые несколько секунд (обычно 10–20 с) в потоке появляются пакеты ECM — Entitlement Control Message. Внутри — зашифрованные control words (DCW), два 8-байтных ключа (odd и even). Без их расшифровки картинки нет.

Смарт-карта с действующей подпиской умеет расшифровать ECM и вернуть DCW. Cardsharing берёт этот DCW и передаёт по сети другим клиентам. Клиент подключается к серверу, отправляет ECM, получает в ответ DCW — и применяет его локально для дешифровки потока.

EMM (Entitlement Management Message) — отдельный тип пакетов, обновляют права на карте. Для базовой настройки EMM менее важны, но OScam умеет их форвардить, что помогает при автообновлении подписки.

Разница между классическим cardsharing и IPTV-доставкой

При классическом спутниковом приёме тюнер сам принимает поток с транспондера. Клиент cardsharing получает ключ и дешифрует поток локально на своём оборудовании. IPTV же доставляет уже готовый видеопоток (часто уже дешифрованный на стороне провайдера) по IP-каналу.

В схеме cardsharing iptv всё немного сложнее: поток может приходить как через DVB-тюнер, так и через IP-стрим в формате MPEG-TS или HLS, а ключи дешифрования запрашиваются у удалённого cardsharing-сервера. Это используется, например, в DVB-over-IP решениях или на Enigma2-приставках с внешним стримером.

Где проходит граница легального использования

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

Протоколы и порты: CCcam, newcamd, MGcamd, OScam

Протоколов для обмена ключами несколько, и у каждого своя специфика. Выбор влияет на задержку, стабильность и совместимость с вашим оборудованием.

CCcam-протокол и порт по умолчанию

CCcam работает по TCP. Порт по умолчанию — 12000, задаётся директивой SERVER LISTEN PORT в конфиге. Строка клиентского подключения выглядит так:

C: host port username password

Протокол проприетарный, бинарный. CCcam-демон на сервере принимает подключения, проверяет учётные данные и начинает отвечать на ECM-запросы. Накладные расходы минимальны, но протокол закрытый — расширяемость ограничена.

newcamd: формат строки подключения и порты

newcamd типично работает на портах 10000–15000. Строка подключения в конфиге клиента:

N: host port username password DES-ключ

DES-ключ — 14 байт в шестнадцатеричном виде, например 01 02 03 04 05 06 07 08 09 10 11 12 13 14. Его нужно указывать идентично на сервере и клиенте. Протокол немного устарел, но до сих пор поддерживается большинством эмуляторов и многими железными ресиверами.

OScam как универсальный шлюз протоколов

OScam — это не просто ещё один эмулятор. Он одновременно понимает cccam, newcamd, camd35, radegast и cs378x, может принимать подключения по одним протоколам и форвардить запросы по другим. Например, CCcam-клиент подключается к OScam, а тот уже передаёт ECM на физическую карту или удалённый сервер по newcamd.

Это делает OScam идеальным хабом в смешанных схемах. Конфигурация подробнее — зато и контроль полный.

Сравнение задержки и стабильности протоколов

CCcam в простой связке «один сервер — один клиент» даёт хорошие результаты. Но при цепочках из нескольких хопов каждый узел добавляет задержку. newcamd немного быстрее на коротких маршрутах из-за меньшего handshake. camd35 (cs378x) показывает минимальную задержку при прямом подключении к карте, но хуже совместим с «бюджетным» железом.

Для cardsharing iptv с частой сменой control word (каждые 10 с) критично, чтобы ECM time не превышал 500–600 мс. Иначе получите фризы.

Настройка OScam: конфигурационные файлы шаг за шагом

OScam хранит конфиги в отдельной директории. Стандартные пути: /etc/tuxbox/config/oscam/ (Enigma2-боксы) или /var/etc/oscam/ (некоторые дистрибутивы). Бинарник обычно в /usr/bin/oscam. Запуск с явным путём к конфигам:

oscam -b -c /var/etc/oscam/

Флаг -b — фоновый режим. Без него OScam запускается в foreground, что удобно при первоначальной отладке.

oscam.conf: глобальные параметры и веб-интерфейс

Главный конфиг — oscam.conf. Минимальный рабочий вариант:

[global]
logfile = /var/log/oscam/oscam.log
maxlogsize = 512
preferlocalcards = 1
saveinithistory = 1

[webif]
httpport = 8888
httpuser = admin
httppwd = secret
httprefresh = 10

Веб-интерфейс по адресу http://192.168.1.x:8888 — ваш главный инструмент мониторинга. Там видно статус ридеров, активные сессии, время ответа ECM в реальном времени. Параметр httprefresh задаёт автообновление страницы в секундах.

oscam.server: описание ридеров и подключений

Каждый ридер — отдельный блок в oscam.server. Пример для CCcam-источника:

[reader]
label = my_cccam_server
protocol = cccam
device = server.example.com,12000
user = myuser
password = mypassword
group = 1
cccversion = 2.3.0
ccckeepalive = 1

Для newcamd-подключения замените протокол и добавьте key:

[reader]
label = newcamd_reader
protocol = newcamd
device = server.example.com,10300
user = testuser
password = testpass
key = 0102030405060708091011121314
group = 2

Параметр group критически важен. Ридеры и аккаунты связываются через номера групп. Если группы не совпадают — клиент не будет получать ответы от ридера, и вы будете долго чесать голову над тем, почему ридер online, а каналы не открываются.

oscam.user: учётные записи и группы

Файл oscam.user описывает клиентов, которые подключаются к OScam:

[account]
user = client1
pwd = clientpass
group = 1
au = 1
betatunnel =
expdate =

Параметр au = 1 включает автообновление прав (EMM). Поле expdate задаёт дату истечения доступа в формате YYYY-MM-DD — удобно для управления тестовыми аккаунтами.

oscam.services и привязка по CAID/provid

Файл oscam.services позволяет ограничить доступ к конкретным пакетам по CAID и provider ID. Пример:

[VIASAT]
caid = 0500
provid = 032830,041200
srvid =

В oscam.user можно привязать аккаунт к сервису: services = VIASAT. В oscam.server — ограничить ридер нужными CAID через caid = 0500. Это важно, если у вас несколько источников с разными пакетами: без маршрутизации по CAID OScam будет опрашивать все ридеры подряд, увеличивая задержку.

Запуск, логи и проверка через webif

После запуска смотрите лог:

tail -f /var/log/oscam/oscam.log

В веб-интерфейсе раздел Readers покажет статус каждого ридера: Connected, Disconnected или Not configured. Раздел EMM и ECM в реальном времени отображают запросы и время ответа. Нормальный ECM time — до 300–400 мс. 600+ — уже проблема.

Настройка CCcam.cfg на клиенте и сервере

Конфиг CCcam по умолчанию находится в /var/etc/CCcam.cfg. Синтаксис простой, но несколько ключевых моментов часто упускают.

Строки C: для клиента и F: для отдачи

Строка подключения клиента к серверу:

C: server.example.com 12000 myusername mypassword

Строка отдачи — для раздачи карт своим клиентам (серверная сторона):

F: clientuser clientpassword 1 0 0 { 0:0:1 }

Формат F-строки: логин, пароль, uphops, downhops, au (0 или 1), и опциональный фильтр CAID. Не открывайте F-строки без фильтров и лимитов — любой знающий логин/пароль получит доступ ко всему, что есть у вашего сервера.

Параметры hops и SHARE LIMITS

Hop — это «прыжок» между картой и конечным клиентом. Hop 1 означает, что клиент напрямую подключён к серверу с картой. Каждый промежуточный сервер добавляет хоп и задержку.

В глобальной секции CCcam.cfg:

SHARE LIMITS : 10
SERVER LISTEN PORT : 12000
MINIMIZE DELAY : yes

SHARE LIMITS ограничивает количество одновременных клиентов. MINIMIZE DELAY включает оптимизацию очереди ECM-запросов — при cardsharing iptv это существенно снижает задержку.

Файлы CCcam.cfg, CCcam.prio и CCcam.channelinfo

CCcam.prio — приоритизация источников при наличии нескольких ридеров с одинаковым CAID. Формат:

P: CAID:provid:srvid = CAID:provid:srvid

Например, если канал доступен от двух провайдеров (два разных provid под одним CAID), через CCcam.prio можно явно указать, от какого источника брать ключ первым. Без этого CCcam выбирает сам — не всегда удачно, отсюда периодические фризы на мультипакетных каналах.

CCcam.channelinfo содержит список каналов с именами и SID — удобно для читаемых логов, на стабильность не влияет.

Совмещение CCcam и OScam на одном устройстве

Запустить оба демона одновременно на одном устройстве можно, но они не должны слушать один и тот же порт. Стандартная схема: OScam принимает CCcam-клиентов на порту 12000, а сам выступает клиентом к внешнему серверу. CCcam при этом либо не запускается, либо слушает другой порт (например 12001).

В oscam.conf добавьте секцию для CCcam-сервера:

[cccam]
port = 12000
version = 2.3.0
reshare = 1

Теперь CCcam-клиенты (ресиверы, плагины) подключаются к OScam как к обычному CCcam-серверу, а OScam сам решает, какому ридеру форвардить запрос. Это мощная схема для мультипротокольных сред.

Диагностика фризов и типичных ошибок

Большинство проблем решаются чтением логов. Но нужно знать, что именно там искать.

Канал не открывается: чтение логов ECM

В логе OScam каждый ECM-запрос выглядит примерно так:

2026/01/15 14:23:01 c (clientname) ECM [CAID:0500/PROVID:032830/SID:1234] found (310 ms) by my_cccam_server

Статус found — ключ получен, всё ок. not found — ни один ридер не смог ответить. timeout — ридер не ответил вовремя (порог задаётся через ctimeout в oscam.conf, обычно 3000 мс).

Если видите not found при живом ридере — почти всегда это CAID/provid mismatch или отсутствие нужного пакета у источника.

Фризы и долгий response time control word

ECM time выше 600–800 мс даёт фризы при частой смене control word. На некоторых каналах смена происходит каждые 10 с, на других — каждые 30 с. Первые дают заметные артефакты уже при 500 мс задержки.

Проверьте в веб-интерфейсе OScam раздел ECM History — там видно время ответа по каждому каналу. Если один конкретный ридер стабильно даёт 700+ мс — проблема в нём (высокий пинг, перегрузка сервера, длинная цепочка хопов). Попробуйте другой ридер или переключитесь на ридер с меньшим числом хопов.

Ошибки CAID/provid mismatch

Ридер online, ECM-запросы уходят, но приходит not found. Классический сценарий: в oscam.server указан неверный provid или вообще не указан, а сервер отдаёт только конкретный пакет. Решение — явно прописать CAID и provid в блоке ридера:

caid = 0500
services = VIASAT

Второй вариант: карта у источника есть, но подписка на запрашиваемый пакет истекла. Тогда ридер connected, CAID совпадает, но ECM возвращает not found на уровне самой карты. Это не ваша ошибка конфигурации — это проблема источника.

Проблемы сети: NAT, firewall, проброс портов

Проверить доступность порта элементарно:

telnet server.example.com 12000

Если соединение не устанавливается — firewall или неверный адрес. Если сервер стоит за NAT без белого IP, клиенты снаружи не достучатся без проброса порта на роутере или без обратного туннеля (например, через autossh).

Отдельная засада — провайдер блокирует нестандартные порты. В этом случае меняйте порт CCcam (например на 443 или 80), хотя это костыль. Более надёжно — VPN-туннель между клиентом и сервером.

И ещё один момент, который почти никто не упоминает: рассинхрон системного времени на ресивере. Если ваше устройство уходит по времени более чем на 30–60 секунд, некоторые реализации протокола начинают отклонять ECM-ответы как устаревшие. Настройте NTP:

ntpdate -u pool.ntp.org

И добавьте в cron или автозапуск. Это реально ломает дешифрование при формально рабочем подключении.

Как выбрать сервер: критерии без привязки к именам

Конкретных провайдеров называть не буду — не потому что скрываю, а потому что рынок меняется быстро, и вчерашний надёжный сервис завтра может исчезнуть. Лучше научитесь оценивать любой сервер самостоятельно.

Показатели стабильности: uptime и ECM time

Заявленный uptime 99.9% ничего не значит без проверки. Реальный тест — подключиться в тестовом режиме и смотреть логи минимум несколько часов, желательно в прайм-тайм (вечер пятницы — суббота).

Что смотреть в логах: среднее ECM time (должно быть стабильно ниже 400 мс), количество timeout событий (приемлемо — единицы за час, десятки — плохо), число хопов (видно в CCcam-логе или в веб-интерфейсе OScam). Хоп 1–2 — хорошо, хоп 3+ — высокий риск нестабильности.

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

Уточните перед подключением, какие именно CAID и provider ID поддерживаются. Распространённые CAID: Nagravision — 1801, Viaccess — 0500, Irdeto — 0604/0606, Conax — 0B00, Cryptoworks — 0D00. Один и тот же CAID может использоваться разными операторами с разными provid — уточняйте оба значения.

Хороший признак — наличие локальной карты у источника (hop 0 или 1), а не перепродажа чужого шара с 3–4 хопами. Это напрямую влияет на ECM time при cardsharing iptv-сценариях с частой сменой ключей.

Тестовый период и прозрачность условий

Нормальная практика — тестовый доступ на 24–48 часов перед оплатой. За это время вы успеете провести полноценный тест в своих условиях: с вашим оборудованием, вашим интернет-каналом, вашими каналами.

Если тест не дают или дают только на час в ночное время — это красный флаг. Также смотрите на адекватность поддержки: задайте технический вопрос до оплаты. Ответ покажет, с кем имеете дело.