CCcam сервер: настройка, конфигурация и запуск в 2026

Поднять рабочий cccam server с нуля — задача решаемая, но только если понимаешь что происходит под капотом. Большинство гайдов сводятся к «скачай, запусти, надейся на лучшее». Здесь я разберу всё по-человечески: протокол, конфиг, логи, безопасность и типичные грабли, на которые все наступают по очереди.

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

CCcam — это протокол cardsharing поверх обычного TCP. Сервер читает ECM (Entitlement Control Message) из зашифрованного DVB-потока, расшифровывает его с помощью физической смарт-карты через CI-ридер или DVB PCI/USB адаптер, получает DCW (Decryption Control Word) и отправляет его клиенту. Клиент кормит DCW декодеру — и картинка есть.

Протокол использует собственный шифрованный handshake при установке соединения: клиент и сервер обмениваются случайными seed-ами, после чего весь трафик идёт XOR-шифрованным потоком. Это не TLS, не SSL — своя примитивная схема, которая тем не менее работает с 2007 года.

Архитектура CCcam: сервер, клиент, решаринг

Схема простая: есть «родительский» сервер с физической картой, к нему подключаются клиенты через C-line. Сервер может одновременно быть клиентом для другого сервера — это называется решарингом. Один сервер тянет карты от двух-трёх апстримов и раздаёт их десяти клиентам ниже.

Каждый пользователь в конфиге описывается F-line (F от «Friend»). Каждое исходящее соединение — C-line (C от «Connect»). Всё хранится в одном файле CCcam.cfg.

Протокол CCcam поверх TCP: порт 12000 и handshake

Стандартный порт — TCP 12000. Handshake выглядит так: клиент коннектится, сервер присылает 16-байтовый challenge, клиент шифрует хеш своего логина/пароля и отвечает. После успешной аутентификации начинается обмен share-листом — сервер сообщает клиенту какие CAID/provider ID у него есть. Дальше клиент шлёт ECM-запросы, сервер отвечает DCW.

Весь этот процесс занимает 50-150мс на нормальном канале. Если у тебя latency до сервера больше 300мс — ECM timeout гарантирован даже на прямом H1 соединении. Физика не обманешь.

Отличие CCcam от OScam, NewCamd и MgCamd

NewCamd — более старый протокол, порт обычно 15000, используется для прямого подключения к серверу с картой без решаринга. MgCamd — клиент, который умеет работать с несколькими протоколами одновременно. OScam — современный сервер, который «говорит» на всех этих протоколах и активно развивается.

CCcam разработка остановилась на версии 2.3.8. Это факт. Последний официальный релиз вышел несколько лет назад, баги не фиксятся. Для нового сервера в 2026 году логичнее смотреть на OScam с CCcam-эмуляцией — он современнее, гибче и умеет IPv6. Но CCcam всё ещё жив на миллионах ресиверов, поэтому знать его нужно.

Что такое hop (H1, H2) и почему H1 стабильнее

Hop — это количество серверов между картой и твоим декодером. H1 = твой декодер подключён напрямую к серверу с физической картой. H2 = между тобой и картой ещё один сервер-ретранслятор. H3 = ещё один.

Каждый дополнительный hop добавляет задержку: реалистично 200-500мс на каждый уровень. На H1 ECM обрабатывается за 80-200мс — нормально. На H3 это уже 600мс-1.2с, и при таймауте декодера в 800мс получаешь freeze каждые несколько секунд. Поэтому H1 стабильнее — просто потому что короче цепочка.

---

Установка CCcam на Debian/Ubuntu сервер

Рассматриваю установку на Debian 12 (Bookworm) — актуальный LTS в 2026. Сервер у меня VPS с 1 CPU, 1GB RAM, и этого хватает для 15-20 клиентов без проблем.

Системные требования: ядро, библиотеки, ia32-libs

CCcam 2.3.8 существует в виде 32-битного ELF-бинарника для x86. На 64-битной системе он не запустится сам по себе — нужна поддержка multiarch. Без этого получишь «No such file or directory» даже когда файл явно существует.

dpkg --add-architecture i386
apt update
apt install libc6-i386 lib32stdc++6 lib32gcc-s1

Если пропустить dpkg --add-architecture i386 — libc6-i386 просто не найдётся в репозитории. Это самая частая ошибка при установке на свежий Debian 12.

Загрузка бинарника CCcam (2.3.x / 2.3.8)

Официального сайта CCcam больше нет. Бинарники версии 2.3.8 давно разошлись по форумам. Скачивай только из проверенных источников — хотя бы проверяй MD5 суммы. Существуют и x86_64 (64-битные) сборки — они работают без libc6-i386, но менее распространены.

После скачивания:

chmod 755 /usr/local/bin/CCcam.x86_64
# или для 32-битной версии:
chmod 755 /usr/local/bin/CCcam.i686

Размещение в /usr/local/bin и права доступа

Создай необходимые директории:

mkdir -p /var/etc
touch /var/etc/CCcam.cfg
mkdir -p /var/log/

Права на конфиг лучше ограничить — в нём хранятся пароли пользователей:

chmod 600 /var/etc/CCcam.cfg
chown root:root /var/etc/CCcam.cfg

Создание systemd unit для автозапуска

Это то, чего нет в большинстве гайдов. Вот готовый unit для Debian 12:

# /etc/systemd/system/cccam.service
[Unit]
Description=CCcam Card Sharing Server
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/CCcam.x86_64 -C /var/etc/CCcam.cfg
Restart=on-failure
RestartSec=10
StandardOutput=append:/var/log/cccam.log
StandardError=append:/var/log/cccam.log
User=root

[Install]
WantedBy=multi-user.target

Активировать:

systemctl daemon-reload
systemctl enable cccam
systemctl start cccam
systemctl status cccam

Флаг -d в ExecStart для продакшн-сервиса не нужен — он перенаправляет вывод в stdout и может вызвать дублирование логов. Для отладки запускай отдельно в терминале.

Установка на Enigma2-ресиверы (Vu+, Dreambox)

На Vu+ Solo4K, Ultimo4K и аналогичных ресиверах с OpenATV или OpenPLi бинарник лежит в /usr/bin/CCcam или /usr/bin/CCcam_2.3.x, конфиг — /etc/CCcam.cfg.

Перезапуск через init.d скрипт:

/etc/init.d/CCcam restart
# или на системах с systemd:
systemctl restart cccam

Старые образы OpenATV 6.x иногда идут с CCcam 2.1.x. Синтаксис F-line там немного другой: параметры uphops/downhops могут не поддерживаться. Если подключаешь современного клиента — обнови до 2.3.8 или переходи на OScam.

---

Конфигурация CCcam.cfg: F-line, C-line, N-line

Весь cccam server живёт в одном текстовом файле. Синтаксис простой, но одна лишняя пробелка или неправильный порядок параметров — и соединение не установится без внятной ошибки в логах.

F-line — настройка клиентских аккаунтов на сервере

F-line описывает пользователя, которому ты раздаёшь шары. Формат:

F: username password uphops downhops groups
# Пример:
F: client01 S3cr3tP@ss 2 0 {}

Параметры: uphops — сколько hop'ов вверх клиент может видеть (обычно 1-2), downhops — сколько hop'ов вниз клиент может решарить (0 = запрещено). Группы {} — пустые по умолчанию, можно ограничить доступ к конкретным картам.

Если хочешь дать клиенту только H1 карты и запретить решаринг:

F: client01 S3cr3tP@ss 1 0 {}

C-line — подключение клиента к удалённому серверу

C-line — это исходящее подключение твоего сервера к другому CCcam-серверу для получения шар:

C: hostname.example.com 12000 myuser mypassword
# Можно добавить параметр want-emu для эмуляции:
C: hostname.example.com 12000 myuser mypassword no

Последний параметр no означает «не хочу эмулированные карты». Если апстрим предоставляет эмуляцию — ставь yes. Реальные хосты и пароли здесь не привожу — это твои данные от провайдера.

N-line — подключение к NewCamd серверу

Если апстрим работает по протоколу NewCamd (порт обычно 15000-15010):

N: hostname.example.com 15000 myuser mypassword 01 02 03 04 05 06 07 08 09 10 11 12 13 14

14 байт в конце — DES ключ. Провайдер NewCamd обязательно его предоставляет. Без правильного ключа handshake не пройдёт.

Параметры: SERVER LISTEN PORT, WEBINFO LISTEN PORT 16001

В начале конфига обязательные глобальные настройки:

SERVER LISTEN PORT : 12000
WEBINFO LISTEN PORT : 16001
ALLOW WEBINFO : yes
WEBINFO USERNAME : admin
WEBINFO PASSWORD : ChangeThisPassword123

# Настройки производительности
ENABLE LAN SUPPORT : yes
EXTRA OPEN PORTS : 0

# Логирование
DEBUG : no
LOG FILE : /var/log/cccam.log
LOG WARNINGS : yes

Веб-интерфейс будет доступен по адресу http://SERVER_IP:16001. Без WEBINFO USERNAME/PASSWORD он открыт всему миру — что недопустимо в 2026.

Управление shares: SHARE LIMIT, SHARE DELAY, MINIMUM DOWNHOPS

Три параметра, которые реально влияют на стабильность, но о которых почти не пишут:

SHARE LIMIT : 3
SHARE DELAY : 0
MINIMUM DOWNHOPS : 0

SHARE LIMIT — максимальный hop, карты которого ты принимаешь от апстрима. 3 — разумное значение. 5 — уже много задержки. SHARE DELAY — задержка в миллисекундах перед отдачей DCW клиенту (обычно 0, повышать не нужно). MINIMUM DOWNHOPS — минимальный hop для карт, которые ты разрешаешь клиентам видеть.

Freeze каждые 10 секунд — это почти всегда SHARE DELAY > 0 в сочетании с высоким пингом. Проверь сначала это.

---

Запуск, логи и веб-интерфейс мониторинга

Запуск в foreground для отладки: CCcam -d

Когда что-то не работает, первый шаг — запустить в debug-режиме прямо в терминале:

/usr/local/bin/CCcam.x86_64 -C /var/etc/CCcam.cfg -d

Флаг -d включает verbose вывод в stdout. Увидишь handshake с каждым клиентом, список принятых шар от апстрима, каждый ECM запрос и ответ. Первые 30 секунд после запуска — самые информативные. Остановить Ctrl+C.

Если система за systemd и сервис уже запущен — сначала systemctl stop cccam, иначе порт 12000 уже занят.

Логи: расположение, парсинг строк ECM/DCW

При нормальной работе лог-файл /var/log/cccam.log содержит строки такого вида:

20260315 14:23:41 CWfound by client01 in 87ms for CAID 0500:000000
20260315 14:23:41 ECM from client01 CAID:0500 PROVID:000000 SID:1234 
20260315 14:23:42 CWnot found for CAID 0604:000000

CWfound — успех, DCW найден за 87мс. CWnot found — карта с этим CAID недоступна на сервере. Если видишь только CWnot found — значит у тебя нет карт для этого CAID.

Веб-интерфейс на порту 16001: разделы Server, Clients, Shares

Открой http://SERVER_IP:16001 в браузере — попросит логин/пароль из WEBINFO USERNAME/PASSWORD. Внутри три основных раздела:

• Server Status — uptime, версия, количество активных соединений, загрузка CPU
• Clients — список подключённых клиентов, их логины, hop-уровни, количество ECM запросов, последняя активность
• Shares / getCards — полный список CAID:ProviderID доступных карт с hop-уровнем каждой

Раздел Shares — твой главный инструмент диагностики. Если клиент говорит «не работает канал X» — открываешь getCards, смотришь есть ли нужный CAID. Если нет — проблема в апстриме, не у тебя.

Команда tail -f и фильтрация по CAID

# Смотреть все события в реальном времени:
tail -f /var/log/cccam.log

# Фильтровать только определённый CAID (например 0500):
tail -f /var/log/cccam.log | grep "0500"

# Смотреть только ошибки:
tail -f /var/log/cccam.log | grep -i "not found\|error\|fail"

Проверка соединения через telnet/nc на порт 12000

# Проверка что порт открыт и CCcam отвечает:
nc -zv SERVER_IP 12000
# или
telnet SERVER_IP 12000

Если видишь «Connected» — сервис запущен и порт открыт. Если «Connection refused» — CCcam не запущен или firewall блокирует. Если timeout — firewall дропает пакеты без ответа (хуже чем refuse, дольше ждать).

---

Решение типичных ошибок CCcam сервера

Ошибка 'card not found' и проверка CAID/provider ID

Это самая частая жалоба. «Карта не найдена» значит буквально: клиент запросил ECM для CAID X с Provider ID Y, а такой комбинации в доступных шарах нет.

Алгоритм диагностики:

1. Открой веб-интерфейс → Shares/getCards
2. Найди CAID проблемного канала (например, Sky Deutschland: CAID 0x0919)
3. Если CAID в списке нет — твой апстрим не предоставляет эту карту
4. Если CAID есть — проверь Provider ID, он должен совпадать с запросом клиента

Hop-уровень в getCards тоже важен. Если карта доступна на H3, а у тебя SHARE LIMIT : 2 — она не будет видна клиентам.

ECM timeout: причины и тюнинг MINIMUM DOWNHOPS

ECM timeout — это когда запрос ушёл, но ответ не пришёл вовремя. Декодер обычно ждёт 800-1200мс. Причины:

• Высокий ping до апстрим-сервера (>300мс) — физически не успевает
• Сервер апстрима перегружен — слишком много клиентов
• Высокий hop-уровень (H3+) — суммарная задержка цепочки

Попробуй снизить SHARE LIMIT до 2 — это уберёт H3 карты и оставит только H1/H2. Иногда помогает добавить второй C-line к другому апстриму как резервный — CCcam выберёт тот, что ответит первым.

'cannot decode' — несовпадение ключей или зашифрованный поток

«Cannot decode» или «Wrong DES key» при N-line подключении — неправильный DES-ключ в конфиге. Провайдер NewCamd периодически меняет ключи — запроси актуальный.

Для C-line аналогичная ошибка обычно означает неверный пароль или что аккаунт отключён на стороне апстрима. Проверь через лог — там будет «AUTH failed for user».

Freeze каждые 10 секунд: проблема с ECM интервалом

Цифра «каждые 10 секунд» — не случайная. Стандартный crypto-period у большинства операторов составляет 10 секунд. Если freeze именно с такой периодичностью — DCW приходит, но слегка опаздывает к смене ключа.

Что проверить:

• Ping до апстрима: ping SERVER_IP -c 20 — стабильность важнее среднего значения
• Убедись что SHARE DELAY : 0
• Если MINIMUM DOWNHOPS выше 0 — попробуй поставить 0
• Проверь что не используешь карты с hop > 2

Connection refused на 12000: firewall, iptables, NAT

Классика — CCcam запущен, но снаружи не достучаться. Пошагово:

# 1. Проверить что CCcam слушает порт:
ss -tlnp | grep 12000
# Должно быть: LISTEN 0.0.0.0:12000

# 2. Проверить ufw:
ufw status

# 3. Открыть порт:
ufw allow 12000/tcp
ufw allow 16001/tcp

# 4. Или через iptables:
iptables -A INPUT -p tcp --dport 12000 -j ACCEPT
iptables -A INPUT -p tcp --dport 16001 -j ACCEPT
iptables-save > /etc/iptables/rules.v4

Если сервер за NAT-роутером — нужен port forwarding на роутере: TCP 12000 → IP сервера. CCcam не умеет UPnP, ручная настройка обязательна. И важный момент: CCcam иногда пытается установить обратное соединение к клиенту (для активного решаринга) — это тоже требует открытого порта на стороне клиента.

Конфликт порта 12000 с другим приложением — тоже бывает. Torrent-клиенты иногда занимают этот порт. Проверь: ss -tlnp | grep 12000 — посмотри какой PID держит порт если CCcam не запущен.

---

Безопасность CCcam сервера

Порт 12000 — публично известный порт cardsharing-протокола. Боты его сканируют регулярно. Открытый cccam server без защиты получит сотни попыток брутфорса в день.

Смена дефолтного порта 12000 на нестандартный

Самое простое что можно сделать — сменить порт на что-то нестандартное, например 47392 или 52841. В CCcam.cfg:

SERVER LISTEN PORT : 47392

Всем клиентам меняешь C-line на новый порт. Это не защита от целенаправленной атаки, но отсекает 95% автоматического сканирования по порту 12000.

Ограничение IP через ACL и fail2ban

Если у клиентов статические IP — добавь whitelist в iptables и дропай всё остальное:

# Разрешить только конкретные IP:
iptables -A INPUT -p tcp --dport 47392 -s 1.2.3.4 -j ACCEPT
iptables -A INPUT -p tcp --dport 47392 -s 5.6.7.8 -j ACCEPT
iptables -A INPUT -p tcp --dport 47392 -j DROP

Для fail2ban — создай фильтр /etc/fail2ban/filter.d/cccam.conf:

[Definition]
failregex = AUTH failed.*from 
ignoreregex =

И джейл в /etc/fail2ban/jail.local:

[cccam]
enabled = true
filter = cccam
logpath = /var/log/cccam.log
maxretry = 3
bantime = 86400
findtime = 600

После 3 неудачных авторизаций — бан на 24 часа. Этого достаточно для большинства ботов.

Защита веб-интерфейса WEBINFO USERNAME/PASSWORD

Порт 16001 тоже сканируется. Обязательно:

WEBINFO USERNAME : someadmin
WEBINFO PASSWORD : V3ryLongRandomP@ssw0rd

Ещё лучше — закрой 16001 от внешнего мира через iptables и открой только для своего IP. Веб-интерфейс нужен только тебе:

iptables -A INPUT -p tcp --dport 16001 -s YOUR_ADMIN_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 16001 -j DROP

Регулярная ротация паролей в F-lines

Каждые 30-60 дней меняй пароли в F-line для активных клиентов. Звучит занудно, но утечка одного пароля означает несанкционированное использование твоего сервера. В логах это видно по аномально высокому числу ECM запросов с аккаунта.

Никогда не используй один и тот же пароль для F-line и SSH-доступа к серверу.

Логирование подозрительных подключений

# Найти IP с наибольшим числом неудачных авторизаций:
grep "AUTH failed" /var/log/cccam.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

# Смотреть подключения в реальном времени:
tail -f /var/log/cccam.log | grep "AUTH\|CONNECT\|DISCONNECT"

Отдельный момент — IPv6. CCcam 2.3.8 не поддерживает IPv6 от слова совсем. Если твой VPS работает на IPv6-only провайдере — нужен 4-to-6 прокси или dual-stack настройка. Многие об этом забывают при заказе нового сервера.

И последнее про безопасность: DDoS на открытый порт 12000 — это реально происходит, особенно если сервер из публичного объявления. fail2ban не спасёт от volumetric DDoS, тут нужна защита на уровне провайдера или хотя бы нестандартный порт плюс geoblocking через iptables если твои клиенты из одного региона.

---