Как работает cardsharing сервер: принцип и архитектура

Если вы когда-нибудь гуглили cardsharing server how it works и находили только маркетинговые страницы с кнопкой «купить линию» — понимаю раздражение. Реальной технической документации на русском почти нет. Ниже — разбор того, что происходит внутри: от ECM-запроса до появления картинки на экране, с реальными портами, конфигами и таймингами.

Что такое cardsharing сервер простыми словами

Базовое определение и зачем он нужен

Cardsharing — это технология совместного использования одной легитимной подписной смарткарты несколькими пользователями через сеть. Сама карта остаётся в card reader, подключённом к серверу. Этот сервер принимает запросы на расшифровку от клиентов и возвращает ключи — всё.

Никакое видео по сети не передаётся. Только короткие криптографические сообщения. Это важно понять сразу, потому что путаница с IPTV начинается именно здесь.

Роль смарткарты, ресивера и сервера

Смарткарта содержит права на просмотр конкретных каналов и умеет расшифровывать специальные сообщения — ECM. Без физической карты сервер ничего расшифровать не может (про эмуляторы поговорим отдельно). Ресивер на стороне клиента принимает зашифрованный спутниковый поток и знает, что ему нужен ключ — но сам его получить не может без карты с активной подпиской.

Сервер — это посредник. Он принимает ECM-запрос от клиента, передаёт его на карту, карта отвечает ключом (control word), сервер отправляет CW обратно клиенту. Готово.

Чем cardsharing отличается от IPTV

IPTV передаёт сам видеопоток через интернет. Вам нужен хороший канал с минимум 5–15 Мбит/с на HD-канал, и если сервер лежит — вы ничего не смотрите. Cardsharing передаёт только 16 байт каждые 7–10 секунд. Видеосигнал приходит прямо со спутника — через антенну на вашей крыше.

Это принципиальная разница. Cardsharing практически нечувствителен к ширине канала (хватит даже 100 Кбит/с), но требует спутниковую антенну и ресивер. IPTV — наоборот.

Архитектура клиент-сервер: как устроен обмен данными

Компоненты системы: card reader, server daemon, клиент

На стороне сервера: физическая смарткарта в card reader (Phoenix или Smargo — два стандарта), daemon (CCcam или OScam), сетевой интерфейс с открытым TCP-портом. На стороне клиента: спутниковый ресивер с DVB-тюнером и softcam (mgcamd, OScam-emu, или встроенный CCcam на некоторых Dreambox).

Card reader подключается к серверу через USB или серийный порт. OScam видит его как /dev/ttyUSB0 или /dev/ttyS0. Без нормального ридера карта либо не отвечает вообще, либо выдаёт неверные CW — частая причина проблем у новичков.

Поток данных: ресивер → клиент → сервер → карта → обратно

Цепочка выглядит так: ресивер тюнируется на транспондер и извлекает ECM из DVB-потока (PID 0x0100–0x01FF). Softcam на ресивере упаковывает ECM в протокол (CCcam/newcamd/cs378x) и отправляет по TCP на адрес сервера. Сервер принимает, находит нужную карту по CAID, передаёт ECM через card reader на смарткарту. Карта обрабатывает — это занимает 50–200 мс — и возвращает CW. Сервер пакует CW в ответ и шлёт обратно клиенту. Клиент передаёт CW в дескремблер DVB-CA — и канал открывается.

Стандартные порты (12000, 10000, 15000) и TCP-соединения

CCcam по умолчанию слушает на TCP 12000. Настраивается в /etc/CCcam.cfg строкой SERVERPORT: 12000. OScam с newcamd-протоколом обычно занимает диапазон 10000–15000, конкретный порт задаётся в /etc/oscam/oscam.server. CS378x (camd35 over TCP) чаще всего живёт на 33333, но это произвольно.

Все соединения — persistent TCP. Клиент коннектится один раз при старте softcam и держит соединение открытым. Если связь обрывается — softcam пытается переподключиться через несколько секунд. Время ожидания реконнекта критично: если оно больше 10 секунд, на экране успеет появиться freeze или чёрный экран.

Роль DVB-CA модуля и CAID/Provider ID

CAID (Conditional Access ID) — четырёхбайтный идентификатор системы условного доступа. Например, Viaccess — 0x0500, Nagravision — 0x1801, Irdeto — 0x0600. Provider ID уточняет конкретного оператора внутри системы. Сервер использует CAID + Provider ID чтобы понять, какая именно карта должна обработать ECM. Если карты с нужным CAID нет — сервер вернёт ошибку "card not found", и канал не откроется. Это одна из самых частых причин "сервер работает, но конкретный канал не идёт".

Протоколы: CCcam, newcamd, CS378x, gbox — в чём разница

CCcam protocol: AES-шифрование сессии, hop-механизм

CCcam — закрытый проприетарный протокол, изначально разработанный для ресиверов Dreambox. При подключении происходит handshake с обменом хэшами (SHA1), затем сессия шифруется AES. Это хорошо с точки зрения безопасности, но закрытость протокола означает, что его поддержка в сторонних клиентах — через реверс-инжиниринг.

Главная особенность CCcam — механизм hop и reshare. В /etc/CCcam.cfg строка SHARE RESHARE LEVEL: 1 означает, что ваши клиенты не смогут раздавать карты дальше. Hop=1 — прямое подключение к физической карте. Hop=2 — между клиентом и картой один промежуточный сервер.

newcamd: формат, аутентификация по DES-ключу

newcamd — открытый протокол, хорошо задокументированный. Аутентификация происходит по 14-байтному DES-ключу, который прописывается в конфиге клиента и сервера. В OScam это выглядит так в /etc/oscam/oscam.server:

[reader]
label        = mycard
protocol     = newcamd
device       = server.example.com,10000
key          = 0102030405060708091011121314
user         = myuser
password     = mypass
caid         = 0500

newcamd работает с привязкой к конкретному CAID, что иногда неудобно при многокартовых серверах. Зато он легко логируется и диагностируется.

CS378x (camd35 over TCP): простота и совместимость с OScam

CS378x — это camd35-протокол поверх TCP, нативный для OScam. Минимальный overhead, нет сложного handshake. Хорошо работает в локальных сетях и там, где важна низкая latency. Совместим с большинством современных клиентов. Если поднимаете собственный OScam-сервер — cs378x обычно лучший выбор для внутреннего трафика.

Когда какой протокол использовать

CCcam — если клиенты используют старые Dreambox или ресиверы, в которых нет нормального OScam. newcamd — универсальный выбор для смешанных окружений, когда нужна широкая совместимость. CS378x — для собственного сервера с OScam на обоих концах. gbox — практически мёртвый протокол, встречается только на очень старом железе, поддержку лучше не рассчитывать.

ECM, EMM и control words: что реально передаётся по сети

ECM (Entitlement Control Message) — запрос на расшифровку

ECM — это короткое зашифрованное сообщение, которое мультиплексировано прямо в DVB-потоке. Оно содержит зашифрованный control word — ключ для дескремблера. Расшифровать ECM можно только смарткартой с нужными правами. Размер ECM — обычно 50–200 байт, не больше. Никакого видео там нет.

Ресивер автоматически обнаруживает ECM в потоке по PID, извлекает его и передаёт softcam. Это происходит каждые 7–10 секунд — с каждой сменой crypto-периода.

EMM (Entitlement Management Message) — управление подпиской

EMM — совсем другое. Это сообщения от оператора для обновления прав на конкретной смарткарте: активация/деактивация каналов, продление подписки, обновление ключей. EMM адресованы конкретной карте по её серийному номеру.

Проблема: операторы шлют EMM постоянно. Если карта используется в нештатном режиме (высокая нагрузка ECM-запросами), оператор может заметить аномалию и отправить EMM, блокирующий карту. Это не автоматика — но мониторинг есть у большинства крупных операторов. OScam умеет фильтровать EMM (emmcache в конфиге), что снижает риск.

Control Word (CW) — 16-байтный ключ дескремблирования

CW — это то, ради чего всё затевается. 16 байт (два 8-байтных слова — odd и even). Дескремблер DVB-CA на стороне клиента применяет CW к зашифрованному видеопотоку и получает чистое видео. Именно это передаётся по сети в cardsharing — 16 байт каждые несколько секунд.

Для понимания масштаба: один HD-канал при 8 Мбит/с требует передачи 16 байт каждые 9 секунд. Это примерно 14 бит/с полезной нагрузки. Остальное — протокольный overhead и шифрование канала.

Почему CW меняется каждые 7–10 секунд

Это называется crypto-период (crypto period). Оператор меняет CW регулярно, чтобы ограничить "окно атаки" — если кто-то перехватит CW, он будет полезен лишь несколько секунд. На практике период у разных операторов разный: Viaccess обычно 9–10 секунд, Nagravision может быть 7. Если ваш клиент не успел получить новый CW до смены периода — на экране freeze. Именно поэтому latency сервера критична.

Жизненный цикл одного запроса на расшифровку канала

Шаг 1: ресивер тюнингуется на канал и получает ECM из потока

Пользователь переключает канал. Ресивер перестраивает тюнер на нужный транспондер (например, 13°E, 11034 МГц, SR 22000). DVB-демультиплексор начинает разбирать поток и находит ECM по PMT (Program Map Table). Это занимает 1–3 секунды при переключении — нормально. Время: T+0 мс.

Шаг 2: softcam упаковывает ECM и шлёт на cardsharing сервер

Softcam (mgcamd, OScam) на ресивере перехватывает ECM через DVB-CA интерфейс, упаковывает его в нужный протокол и отправляет по TCP на сервер. Если соединение уже установлено (persistent TCP) — это мгновенно. Сетевая задержка до сервера: обычно 10–80 мс в зависимости от географии. Время: T+10–80 мс.

Шаг 3: сервер находит карту с нужным CAID и передаёт ECM

Сервер разбирает запрос, смотрит на CAID и Provider ID, находит подходящую карту в своём пуле. Если карта занята (обрабатывает запрос от другого клиента) — запрос встаёт в очередь. OScam умеет это делать умно через систему приоритетов. ECM передаётся через card reader на физическую карту. Время: T+80–150 мс (включая очередь).

Шаг 4: карта возвращает CW, сервер шлёт обратно клиенту

Смарткарта обрабатывает ECM за 50–200 мс — это физическое ограничение чипа на карте, его не ускорить. Карта возвращает CW серверу через card reader. Сервер пакует CW в ответ протокола и отправляет клиенту. Обратная сетевая задержка: ещё 10–80 мс. Время: T+150–350 мс суммарно.

Шаг 5: дескремблер применяет CW и пользователь видит картинку

Softcam передаёт полученный CW в дескремблер DVB-CA ресивера. Дескремблер применяет его к буферизованному зашифрованному потоку — и картинка появляется. Весь цикл в хорошем сценарии занимает 150–350 мс. Если сервер далеко или перегружен — 400–600 мс, что уже на грани: при 9-секундном crypto-периоде запрос нужно успеть отправить заранее. Softcam делает это — шлёт следующий ECM заблаговременно, ещё до истечения текущего периода.

При потере TCP-пакета softcam ждёт timeout (обычно 500 мс в mgcamd) и повторяет запрос. Если retry тоже не успевает — на экране секундный freeze, потом картинка восстанавливается.

Производительность и ограничения: ECM/s, hop, reshare

Лимит ECM в секунду на одну карту

Одна физическая смарткарта обрабатывает от 3 до 5 ECM в секунду — это физический предел чипа. При 10-секундном crypto-периоде это значит, что карта может обслуживать не более 30–50 клиентов теоретически. Но на практике разные клиенты смотрят разные каналы — каждый канал = отдельный CAID+ECM поток. Реально стабильно работает 5–15 клиентов на один канал, если они не переключают каналы синхронно.

Если клиентов больше — начинается очередь. Запросы обрабатываются последовательно. Те, кто не успел получить CW до смены периода, видят freeze. Решение — несколько карт для популярных пакетов.

Hop-механика: hop=1, hop=2 и почему провайдеры режут глубину

Hop — количество серверных звеньев между клиентом и физической картой. Hop=1: ваш softcam подключён напрямую к серверу с картой. Hop=2: между вами и картой есть промежуточный сервер. Каждый hop добавляет 50–150 мс latency — плюс время обработки на промежуточном узле.

При hop=3 суммарная задержка легко превышает 400–500 мс, и freeze становятся нормой. Именно поэтому грамотные провайдеры ограничивают reshare: в CCcam это SHARE RESHARE LEVEL: 0, в OScam — reshare = 0 в профиле клиента. Они хотят контролировать нагрузку на карты и не позволять клиентам перепродавать доступ с деградацией качества.

Reshare: контролируемая раздача ключей дальше

Reshare — возможность клиента в свою очередь стать сервером и раздавать карты дальше. В CCcam настраивается через параметр SHARE RESHARE LEVEL. При значении 1 клиент может раздавать карты на один уровень вглубь (своим клиентам, которые будут hop=2 от оригинальной карты). При 0 — reshare запрещён.

OScam управляет этим через reshare и reshare_mode в /etc/oscam/oscam.user. Там можно тонко настроить: разрешить reshare только для конкретных CAID или только для определённых пользователей.

Влияние количества клиентов на стабильность

Нелинейная зависимость. При 5 клиентах на канал — всё отлично. При 10 — иногда freeze при одновременном переключении. При 20 — freeze регулярные. Хороший сервер решает это через load balancing между несколькими картами одного пакета. OScam умеет это нативно — если прописать несколько ридеров с одним CAID, он распределяет запросы между ними автоматически.

Как выбрать cardsharing провайдера: технические критерии

Local card (hop=1) vs reshare (hop=2+)

Это самый важный критерий. Hop=1 означает, что у провайдера физическая карта стоит прямо в сервере, к которому вы подключаетесь. Hop=2 — он сам является перекупщиком. Разница в latency: 100–200 мс против 200–400 мс. На практике это разница между стабильной картинкой и периодическими freeze.

Как проверить? В логах OScam или CCcam виден hop при подключении. В OScam смотрите в /var/log/oscam/oscam.log строки с hops. В CCcam можно проверить через веб-интерфейс на порту 16001.

Uptime сервера и резервирование карт

Серьёзный провайдер держит uptime выше 99%. Но важнее — резервные карты: если основная карта заблокирована оператором или зависла (это бывает), должна быть замена без ручного вмешательства. Хороший OScam-сервер умеет автоматически переключаться между ридерами при недоступности карты.

Перед тестовым периодом спросите: есть ли резервные карты, как быстро переключение происходит автоматически, какой реальный uptime за последние 30 дней.

География сервера и пинг до клиента

Сервер в той же стране или соседней — это 10–30 мс против 80–150 мс для сервера в другом регионе. При hop=1 разница некритична: суммарный цикл всё равно укладывается в 200 мс. Но при hop=2 дополнительные 100 мс пинга могут стать той самой каплей, которая превращает нормальную трансляцию в слайдшоу.

Поддержка протоколов и обновлений ключей

Убедитесь, что провайдер поддерживает протокол вашего ресивера. Если у вас старый Dreambox с нативным CCcam — нужен CCcam-сервер или OScam с CCcam-эмуляцией. Современный ресивер с OScam — cs378x или newcamd будет оптимальным выбором.

Также важно: как быстро провайдер обновляет ключи при обновлениях от оператора? Некоторые операторы меняют BISS-ключи или обновляют EMM раз в несколько месяцев. Если провайдер спит — вы сидите без картинки несколько дней.