Cette documentation est faite pour les utilisateurs qui désirent aller derrière les coulisses de cet EMU afin de connaitre le pourqoui du comment. Il y a des chemins plus faciles (bluepanel & co) mais lorsque que tout ne vas pas comme on veut, il est alors difficle de savoir pourquoi
Installer CCcam
Au début pour les débutants:
Pour pouvoir bien "bricoler" avec sa dream, nous aurons besoins de différents petits programmes à se procurer avant de commencer
1. Un éditeur compatible Linux, par exemple ultraedit32, Notepad++ ou Crimson Editor (freeware)
2. Un programme FTP comme FlashFXP
3. Un outil syslog comme 3csyslog (freeware)
4. Un outil Telnet, celui intégré à Windows fera l'affaire
Installation du CCcam
CCcam se compose de deux fichiers, un binaire et un .config. Dans le .rar original, les auteurs ont nommé le fichier binaire pour la dreambox CCcam.ppc,
Quant au fichier .config, c'est le même pour toutes les versions. Je conseille de renommer le fichier binaire en CCcam, cela simplifiera la suite des opérations avec telnet. Ensuite copier dans /var/bin et donner les droits (attributs) 755. Le fichier CCcam.cfg sera copié quant à lui dans /var/etc/
Premier démarrage de l'EMU
Cette ligne est juste la pour ceux qui copie ce cours sans même le lire en détail. Ce cours est l'oeuvre de Tissa de Dream-Pirates et est continuellement actualisé.
Maintenant nous sommes prêts à démarrer l'EMU, sans script, nous devons le faire par la console telnet. C'est vraiment pratique, car on voit de manière détaillée ce que fait vraiment l'EMU.
Pour windows
Démarrer -> exécuter -> telnet 192.168.1.10 (=IP du box)
Saisir l'utilisateur (=root) et le mot de passe (=dreambox, si celui-ci n'a pas été modifié)
Aller dans le répertoire /var/bin (saisir cd /var/bin) et contrôler si vous êtes réellement dans celui-ci (ls = dir sous linux)
On reconnait aux différentes couleurs quel attribut a un fichier, notre CCcam devrait être vert.
Pour démarrer taper CCcam -dv (attention minuscule/majuscule), le paramètre est pour permettre la visualisation du log à la console telnet
De cette manière, on voit directement ce que le CCcam fait, cela devrait ressembler à cela:
Si on pense que quelque chose n'est pas correct dans le déroulement du décryptage avec le CCcam, les informations relativent aux ecms (demandes de clés) apparaissent directement en zappant.
Si l'on veut vraiment savoir si l'EMU tourne, simplement ouvrir une seconde session telnet et taper ps et les processus actifs seront visibles. Cela ressemble à cela:
Les entrées dans le log:
online using nodeId 578103ff60952939 Chaque utilisateur CCcam Serveur/Client reçoit un identifiant unique pour sa connexion.
create 2 cam device(s) la 7020 a reconnu 2 lecteurs actifs, sur les lignes suivantes apparaissent les données relatives aux cartes
provider num: 021c00 est le numéro du provider, dans ce cas Redlight/FullX
card added to broker with caid 500 c'est le caid (Cryptage standard) que gère cette carte, dans notre cas c'est le Viacess. La carte est identifiée par une combinaison caid/provider, dans notre cas 0500:021c00. Parfois certains providers utilisent plusieurs caids, c'est pour cela que notre Redlight/FullX dispose aussi du Irdeto Version 0600:021c00. Le système caid/provider sera plus tard très important, donc retenez bien cela.
added 389 keys il y a 389 clés lues depuis le Keyfile
static cw not found or bad il n'y a pas de static.cw disponible, ceci n'est pas tragique pour la suite (optionnel)
read_ignorefile: cannot open /var/keys/CCcam.ignore or not found aussi optionnel, pas important pour la suite non plus.
server started on port 12000 Le serveur tourne sur le port 12000 TCP (Important pour paramétrer son Router/Firewall)
Keyfiles
Les Keyfile sont lus depuis le répertoire /var/keys (à condition de ne pas l'avoir changé dans le fichier de configuration).
Le CCcam utilise le format étendu SoftCam.key/Autoroll.key, que d'autres EMU utilisent aussi. De ce fait, on n'est pas lié à un format spécifique pour cet EMU. Les Keyfile sont optionnels, l'EMU fonctionne aussi sans.
CCcam et Cardsharing
Maintenant, on va relier les CCcams. Pour cela, il faut éditer le fichier /etc/CCcam.cfg (pas avec le l'éditeur bloc-note de Windows comme cité plus haut).
Le fichier de configuration standard est aussi un petit manuel d'utilisation. Chaque ligne commençant par # est ignorée par l'EMU, il s'agit dès lors d'un simple commentaire. L'ordre des lignes n'a aucune influence, au démarrage l'EMU charge la configuration et interprète les lignes prenant le premier caractère pour créer l'ordre d'exécution.
F: Friends
Cette ligne F (friends) est pour le serveur, elle définit un utilisateur et son mot de passe. Le numéro qui suit, définit le niveau que ce client peut accéder.
Par exemple avec 1, le client ne verra que mes cartes, avec 2 les autres serveurs qui me sont directement reliés, avec 3 les serveurs reliés à ces serveurs qui me sont reliés, etc. Cela se nomme du cascading et cela peut vite atteindre un grand nombre de cartes.
C: Connect
C: server.dyndns.org 12000 user1 pass1
Cette ligne C (connect) permet au CCcam de se connecter à un autre serveur. L'URL ou l' IP après le C: servira aussi à l'identification du serveur sur le réseau de sharing, 12000 est le port avec lequel travaille le serveur et user1 pass1 indentifie l'utilisateur.
Important: un même utilisateur n'est accepté qu'une seule fois par serveur.
Veut-on juste connecter un client à un serveur, la ligne F: côté serveur puis la C: côté client suffisent donc pour cela. Si l'on veut faire également partager les cartes du client au serveur, il faut ajouter une ligne C: au serveur et F: côté client.
Diagnotisque par le log
Une fois que l'on a tout fait cela, on peut démarrer les CCcams de chaque côté par telnet en utilisant la commande CCcam -dv et observer si une connection se fait. Au début, il est judicieux d'utiliser telnet pour tester, ensuite quant tout est bon on pourra charger le script par le Blue Panel qui le fera automatiquement.
Voici à quoi devrait ressembler le log entre les deux boxs de test chez vous:
Sur les 3 premières lignes est affichée la manière dont est crypté le canal. Pre***e apparait avec les 3 caids possibles:
1801 Nagra pur (pas utilisé ou uniquement avec carte s04) = sans signification
1702 Tunnel Nagra = betacrypt pour satellite
1722 Tunnel Nagra = betacrypt pour le câble
Le provider id bei Pre***e, id:0x0, habitullement écrit à 6 chiffres 000000
Le id est le programme identifié, dans ce cas 100a, il sagit donc de la chaîne Pre***e 1
Avec start EMM la recherche de la clé est démarrée
Les 2 lignes suivantes contiennent les réponses du serveur local. Les réponses sont négatives ! ecm even nok caid:0x1722 . Normal, il n'y a pas de carte dans ce récepteur. La demande a duré 0003s.
Ensuite regardons les demandes au serveur :
Cette demande a été executée avec succès, ...ecm even ok caid:0x1702... et a été effectuée par le LAN en 0.1383s.
Arrêt du serveur
Aussi longtemps que l'on se trouve dans le log par la console telnet, Ctrl+c suffit.
Sinon, il faut par telnet saisir la commande killall CCcam pour terminer.
Le serveur web integré
CCcam propose un moniteur web qui présente l'état actuel de l'EMU et de ses connections. Avec les paramètres par défaut, celui-ci tourne sur le port 16001. Pour y accèder avec le browser, ne pas oublier de spécifier le protocolehttp://ip_du_box:16001 .
Dans ce moniteur les clients actifs, les clients, l'état des serveurs sont clairement indiqués
Dans notre exemple, il doit y avoir un accès défini pour le client sur un serveur. Si cet accès est défini, la communication s'établit et l'image apparait
La page avec les clients actifs ressemble à cela. Dans la première partie, il y a les utilisateurs actifs durant les 20 dernières secondes et le nombre d'ECM obtenus. Dans la partie inférieure, se trouvent listé tous les utilsateurs et le résumé du trafic. Le trafic qui est décrypté localement est d'ailleurs différencié de celui qui est tranféré plus loin (remote)
Log avec Syslog
Celui qui a déjà travaillé avec la console telnet pour visualiser le log, reconnait que ce n'est pas toujours la manière la plus simple et la plus pratique pour rechercher des erreurs de l'EMU. Pour ne pas devoir chaque fois démarrer l'EMU en mode -dv dans la console, il y a l'outil syslog, comme 3cSyslog qui permet de visualiser le log. Pour cela, il suffit de mettre les deux paramètres suivant à YES:
Si on démarre maintenant le CCcam avec le paramètre -V, l'EMU écrira dans le syslog de la dreambox.
Pour voir ce syslog avec le logiciel sur son PC, il faut tout d'abord l'activer sur la dream. Pour Gemini, cela se trouve sous Punkt Sys/Kernel Log dans le Blue Panel sous(3) Extra/Paramètres-> Sys/Kernel Log.
Activer le Syslog-Daemon et tout en bas activer aussi "remotes logging" et saisir l'adresse du Host = IP du PC avec 3cSyslog, le port est le 514 (UDP). Redémarrer le service.
Dès maintenant le log devrait apparaitre en temps réel sur le PC
Le 3cSyslog fonctionne aussi pour d'autres EMU, comme Camd3 ou Newcs, dans ces cas-là, il suffira d'entrer le port 514 dans leur config. Le Syslog-Daemon n'est par contre pour ces deux EMU pas nécessaire.
Connection avec d'autres EMU
Camd3
CCcam peut lire les sharing (=partages) camd3, mais ne peut pas être serveur pour Camd3. Attention, cela fonctionne que pour des partages UDP de camd3 (ce sont ceux dont la ligne de connection commence par 357 dans le camd3.servers 357).
La Ligne L: relie CCcam a un serveur camd3, ensuite il faut donner: IP ou Url du serveur, port UDP du serveur, utilisateur et mot de passe puis caid/provider.
Là encore les numéros caid/provider reviennent (voire partie 1), ces numéros sont nécessaires pour camd3 afin qu'il s'y retrouve parmis ses cartes ou softkey. Si le serveur camd3 dispose de plusieurs cartes donc plusieurs caid/provider, il faudra saisir une ligne L: pour chacune.
Radegast
La ligne R: Line relie CCcam à un serveur radegast, pour cela les paramètres suivants doivent être saisis: IP ou Url du serveur, Port du serveur , utilisateur et mot de passe puis caid/provider
Comme pour camd3, une ligne R: par carte doit être saisie
Newcamd (Newcs)
La connection à un serveur Newcamd est plus simple, car avec Newcamd, lorsqu'un client se connecte, ce serveur informe ce qu'il met à disposition.
La ligne N: relie CCcam à un serveur Newcamd (par exemple NewCS ou Newcamd), pour cela les données suivantes sont requises: IP IP ou Url du serveur, port du serveur, utilisateur et mot de passe puis la DesKey utilisée pour le cryptage de la communication.
Le CCcam actuellement (V 1.2.1) ne peut pas encore lire toutes les sortes de cartes, de ce fait des Cardreaders sont nécessaires dans plusieurs cas de figure. Un des meilleurs Cardreader est incontestablement NewCS comme serveur travaillant avec le protocole NewCamd.
Une particularité du protocolle NewCamd est son login bi-directionnel entre le client et le serveur. C'est avec cela que l'on voit dans NewCS par exemple, quel Emu est utilisé par chacun des clients connectés. Si on ne veut pas communiquer au serveur quel EMU on utilise, alors il faut activer le mode Stealth:
A-t-on justement un paramétrage actif Newcamd sur sa dream, alors on peut simplement avec
reprendre ces paramètres sans rien devoir ressaisir
Configuration de NewCS
Bien que NewCS n'a rien à voir avec CCcam, il est une condition pour pouvoir lire des cartes que CCcam ne peut pas (encore) lire, comme Nagra 2. De ce fait, on va s'y intéresser d'un peu plus prês.
Newcs comme CCcam est composé de 2 fichiers, l'exécutable newcs (binary) qui se trouve dans /var/bin/newcs et qui doit avoir l'attribut 755 et le fichier de configuration /var/tuxbox/config/newcs.xml au format XML.
Xml est conçu comme Html , il contient des tags ou balises, qui une fois ouverts doivent toujours être refermés. Ces tags contiennent les Infos pour le Cardserver.
Un petit extrait d'un fichier newcs.xml
Dans cette partie, on trouve la configuration du lecteur inférieur (/dev/sci0) d'une Dreambox. On ne va pas s'attarder sur les différents tags mais seulement au port communication qui sera utilisé ensuite par le CCcam. Ici on fixe pour chaque carte un port bien définis. Ce port doit ensuite se retrouver dans la ligne N: du CCcam.cfg.
Ici le serveur Newcamd est activé et la Deskey est définie (utlisée pour le cryptage de la communication) et que l'on retrouvera donc dans le CCcam.cfg.
Ce qu'il manque encore pour terminer notre ligne N: ce sont les utilisateurs et mots de passe qui sont définis dans le tag suivant (dummy/dummy). Ensuite on trouve l'AU (autoupdate). Notre ligne N: resseblera à cela si le serveur NewCS est en local:
Lorsque l'on utilise NewCS comm cardreader, celui-ci doit être démarré avant le CCcam. Il est donc conseillé d'ouvrir deux sessions telnet, une pour le NewCS et l'autre pour le CCcam.
Friends (Clients) et cascading
Comme énoncé dans la partie 1, le CCcam gére remarquablement le cascading.
Nous avons pour notre test 4 box, le 1er est relié avec le 2ième, le 2ième avec le 3ième, le 3ième avec le 4ième. Ce sont les seules connections, la 1ère n'est pas reliée directement avec la 4ième. Mais par le cascading le 1er box peut accéder au 4ième.
Si le box1 prend la clé depuis le box4 (cette opération est nommée ecm)
Cette demande puis la réponse passe à travers 3 box que l'on nomme hops
.
Cet utilisateur peut voir les cartes locales du serveur et encore 2 hops plus loin.
Avons nous cet utilisateur dans le box2, donc le box1 pourrait accéder avec au box2, box3 et box4.
Comme cela le box1 pourrait accéder au box2 et un hop plus loin au box3.
Lecture des Keyfiles locaux et EMM distants
Nous avons vu le paramétrage de base pour un utilsateur, il y a aussi moyen d'aller encore un peu plus loin:
Les 3 chiffres après l'utilsateur/mot de passe signifie:
- Le premier est le nomre de hops comme décrit plus haut
- Le second indique si cet utilisateur a accès au keyfile local
Cette option est très pratique quand on a plusieurs box à la maison et que l'on ne veut pas gérer le fichier Softcam.keys dans chacune. Alors on ne le mettra à jour que dans le serveur et important, il faudra alors mettre un yes à la fin de la ligne C:
Par défaut, le deuxième chiffre est à 1, ce qui signifie que lorsque que l'on a simplement définis un utilsateur avec un seul chiffre (pour les hops), il aura accès aux clés locales. Pour l'en empêcher, il faut mettre un 0.
- Le troisième chiffre est pour les EMM distants. S'il y a 1, l'utilisateur pourra effectuer des EMM sur la carte.
Par exemple: il y a un changement de clé, la nouvelle clé est envoyée par le signal TV et pour être actualisée le serveur doit être enclenché sur le bon canal.
Si l'EMM distant est autorisé, il suffira qu'un client de ce serveur soit sur ce canal pour faire la mise à jour. Il fait un update distant que l'on nomme REMM (remote EMM). Par défaut cette valeure est a 1 et permet aux utilisateurs de faire des REMM (remote emm)
Par défaut, il y a ici une valeur 1, de manière que seul un utilisateur directement connecté (1 hop) puisse faire un REMM.
A partir de la version 1.3.0, il est aussi possible à des clients situés à 2 hops de faire également des (R)EMM. Pour cela il faut paramétrer de la manière suivante:
Si on utilise un serveur sans réception satélite, donc sans réception d'EMM, alors on peut totalement arrêter les EMM locaux. Cela économise le processeur et les updates doivent alors venir des clients.
Encore une fois comme résumé:
Cet utilsateur voit les cartes du serveurs et peut faire encore 3 hops après lui.
Il n'a aucun accès au keyfiles du serveur et ne peux pas faire d'EMM.
Droits individuels pour chaque carte UP- et DOWNshare
Cela devient encore un petit peu plus compliqué, il est possible de definir pour chacune des cartes les paramètres suivants:
Cet utilisateur ne peut (à cause du premier 0: pass2 0 1 0 ) qu'accéder aux cartes locales du serveur (dans notre exemple, il y a 3 cartes disponibles)
Il peut accéder aux clés locales (pass2 0 1 0)
Il ne peut pas faire d'EMM (pass2 0 1 0 )
Il n'a aucun accès à la carte 0100:000080 car il n'y a rien après (0100:000080,)
Il a accès à la carte 0622:000000, mais que pour lui = 1downhop (0622:000000:1, )
Il a accès à la carte 0500:000000, et peut la redistribuer un hop plus loin = 2 downhops (0500:000000:2)
Donc on peut définir non seulement combien de hop un client au delà du serveur peut aller (uphops), mais aussi jusqu'à quel niveau un client pourra repartager les cartes (downhops)
Encore un exemple:
Cet utilisateur reçoit (par le chiffre 5 juste après le mot de passe (...pass2 5 0 1 ...) les cartes locales du serveur et les autres cartes jusqu'à 5 hops au delà du serveur.
Il ne reçoit aucune clés locales mais peut faire des REMM sur les cartes du serveur.
Dans les paranthèses, il y a 0 pour Caid et 0 pour les services, ce sont des jokers, cela signifie tous les caids et tous les services jusqu'à 3 niveau plus bas.
Donc cet utilisateur recoit l'accès à toutes les cartes du serveur et encore 3 hops pour le downsharing sauf pour la carte 0100:000080 qui est explicitement autorisée que pour un seul hop (...0000:1...), donc que lui seul pourra utiliser.
Voici en résumé toutes les posibilités de la ligne F:
Jusqu'à maintenant, on a toujours démarré notre EMU avec telnet de manière à pouvoir observer son log. Observons maintenant le script qui permet de démarrer respectivement d'arrêter l'EMU.
Le chemin d'accès au script dépend de l'image utilisée.
Gemini
Pour les images Gemini, tous les scripts se trouvent dans /usr/script. Les scripts concernant un EMU qui doivent apparaître dans le Bluepanel doivent se terminer par _cam (par exemple CCcam_cam.sh).
Attention: les scipts activables doivent portés l'attribut 755.
Les scripts originaux Gemini commencent par une liste de CAMID's. Un domaine est attribué à chaque EMU. Cette liste est juste pour informtion et peut être ignorée.
Le CAMDID est fixé comme ci-dessous:
Le CAMID sert à fixer l'ordre dans la liste dans le BluePanel. Chaque CAMID ne doit apparaitre qu'une seule fois de manière que Gemini puisse retrouver l'EMU par son numéro.
Si la dreambox est redémarrée, Gemini recherche le script avec le numéro sauvé lors de son extinction et le démarre. Si Gemini ne retrouve aucun script avec ce numéro alors apparaît le message " cam id non trouvé"
Ce n'est pas grave pour autant, c'est juste qu'il n'y a pas de script trouvé avec ce numéro de CAMID.
La lecture du script disponible (avec _cam.sh à la fin) s'effectue au démarrage d'Enigma ou lorsque dans le Bluepanel par le menu 1 Réglages CAM -> Tout les cam-> Mise à jour liste des cam. Donc inutile de s'inquiéter si un nom d'EMU modifé n'apparait pas de suite dans le Bluepanel
Le CAMNAME est la désignation qui apparait dans le Bluepanel.
Si on utilise différents skins, faire attention à la longueur de cette désignation, ne pas la faire trop longue.
C'est le temps qu'a besoin l'EMU avant de pouvoir afficher une image lors d'un changement d'EMU.
C'est le fichier ou sont stockés les infos ECM courantes (Avec Gemini on peut aussi les afficher sur le skin)
Maintanent commence le script:
D'abord le paramètre (start ou stop) est lu au démarrage du script
Si start) - est la valeur du paramètre, il se passe ceci echo "[SCRIPT] $1: $CAMNAME" - affiche simplement le nom du script, la valeur du paramètreme et le nom du CAM /var/bin/CCcam -v - maintenant CCcam vient démarré, Dans l'exemple, il y a encore le paramètre -v (verbose) pour sortie du log par le syslog, ceci étant spécifique à cet EMU.
28-06-08, 04:34
1. Cours CCcam: Partie 1 Bases et installation
