holas,

en respuesta de qué es eso del card sahring pues ahí va lo que el compañero Doctor Rayo ha escrito en otra sección de este Foro (muy interesante por cierto ), y creo que es a lo que se refiere el readme del HDL (yo tb lo leí). Entiendo que consiste en dirigir la investigación no al desencriptado (cosa prohibida) sino de otro modo.
Copio y pego. Repito que no es mio, sino del compañero DOCTOR RAYO:

" MANUAL PARA UN CARDSHARING ALTERNATIVO
MANUAL PARA UN CARDSHARING ALTERNATIVO


Bueno...Me he decidido a escribir este manual porque creo que ya ha llegado el momento de hacerlo. Después de haber visto lo que se está cociendo en el mercado de la televisión digital, la cosa se está poniendo muy pero que muy difícil. La época de las emuladoras, los softwares emuladores y demás paridas toca a su fin y es hora de ponernos manos a la obra con diferentes métodos de DPPW (Don´t Pay Per View). Por lo tanto quiero ofreceros un nuevo y apasionante sistema para seguir disfrutando de nuestra diversión favorita. Pero para ello es necesario cambiarse el chip. Se acabó el tema de comprar tarjetas emuladoras. Se acabó el tema de comprar decodificadores sin tarjetero o sin slot para CAM. Y llegó el momento de aprovechar las nuevas tecnologías. Llegó la hora de INTERNET.

ANTECEDENTES

El CardSharing no es un concepto nuevo. Lleva ya algún tiempo en este mundillo pero es algo reservado para, digamos, entornos VIP. “Compartir la Tarjeta”, que sería una traducción apropiada para ello, es un método cada vez más escuchado. El concepto es sencillo: Un decodificador con una tarjeta original está conectado a Internet, y por la red, otros llamados “Clientes” se conectan a él para solicitarle la información necesaria para decodificar el frame de video que se recibe por la antena parabólica. En este punto quizás convendría decir que para entender todo esto en su extensión, el lector tendría que conocer la base de lo que es una transmisión de TV digital PPW (Pay Per View), o lo que es lo mismo, saber el proceso involucrado entre que el decodificador recibe la señal de televisión y el de que la tarjeta lo decodifica para, al fin y al cabo, conseguir lo que se persigue: decodificar la señal de video. Expliquemos un poco todo esto.

La antena parabólica recibe la señal de vídeo de un proveedor determinado. Esta señal pasa al decodificador a través del cable y llega hasta el decodificador. Como todos sabemos, esta señal está CODIFICADA y necesita de un proceso que la transforme para que pueda ser vista en forma de vídeo y audio. Junto con esta señal codificada, viaja tambien la llave para abrirla, es decir para decodificarla. Esta llave es la que el decodificador entrega a la tarjeta para que esta realice todas las operaciones algorítmicas necesarias y la transforme en una llave apropiada con la que el decodificador pueda hacer lo propio, es decir, DECODIFICAR la señal encriptada. A la llave que el decodificador entrega a la tarjeta a través de su tarjetero se le llama ECM y a la llave que la tarjeta entrega al decodificador se le llama DCW. Nada más. Así de simple. La DCW es lo que el decodificador necesita para que podamos ver la señal de vídeo.

Visto lo anterior, es tan sencillo como pensar que teniendo una DCW válida tenemos suficiente para ver la TV digital. Casi si, si no fuera porque el proceso antes descrito se repite cada 10 segundos aproximadamente, con lo que es imprescindible que la tarjeta esté siempre insertada en el decodificador.

Lo que el CardSharing propone es poder obtener la DCW de una fuente distinta que no sea una tarjeta, o mejor dicho, sin la necesidad de que una tarjeta esté conectada físicamente en el decodificador. Aquí es cuando entra en juego INTERNET. Al decodificador le da igual si la DCW la obtiene de una tarjeta real, o de un circuito electrónico que “simula” a una tarjeta. Ese circuito electrónico puede ser uno tal que esté conectado remotamente a un servidor de DCW’s...Y qué mejor servidor de DCW’s que un decodificador que SI tenga instalada físicamente una tarjeta original del proveedor...Se trata pues de, en cierta forma, extender el conector del tarjetero del decodificador hasta un sitio remoto donde de verdad está la tarjeta original.


Este concepto lo saben aprovechar muy bien algunas marcas de decodificadores que tienen incorporado un stack TCP/IP y un conector ethernet y cuyo firmware está preparado para el CardSharing. Una marca muy famosa es DreamBox que incorpora un servidor IP en Linux y al que pueden conectarse otros decodificadores de la misma marca. El CardSharing ya existe, pero como en muchas otras cosas de la vida, no es estándar...Está muy limitado a un par de marcas.


ESTADO ACTUAL DEL MERCADO

El chollo se acaba...cada vez es más evidente. Por eso hay que recurrir a otras estrategias que permitan, en cierta forma, seguir con la investigación, aunque esta vez de manera diferente. No se trata de decirle al público que se compren decodificadores con una boca ethernet y que tengan un stack TCP/IP y que con eso ya podrían volver a ver la vida digital...Se trata de reutilizar lo que ya existe, o por lo menos reutilizarlo en gran medida.

Otra opción existente es hacer CardSharing con una tarjeta SEASON conectada a un ordenador y en este un pequeño programa que se conecte al servidor y que haga de puente entre el decodificador y la tarjeta remota. Tambien se suele hacer, pero es muy engorroso...Es imprescindible usar un ordenador y no todo el mundo está dispuesto a tener un ordenador pegado al decodificador...Tambien funciona este método, por supuesto. Pero es incómodo.

Ahora bien, existe otro método...Y es usar un microprocesador con una interfaz ethernet propia para realizar lo más difícil de todo el tema, y esto es el conectarse con el servidor y extraer la DCW dada una ECM determinada.

Imaginaros el siguiente escenario: Una placa electrónica parecida a una SEASON o a un BLOCKER que se inserta en el tarjetero del decodificador u que en su otro extremo tiene un microprocesador con todo lo necesario para poder comunicarse con el decodificador, obtener la ECM de él y enviarla por internet a un servidor donde hay una tarjeta original(esto puede ser un ordenador con un Phoenix TE21 conectado a su puerto serie). Este servidor procesaría la ECM y devolvería la DCW. Nuestro circuito electrónico obtendría esta DCW y se la entregaría al decodificador...Y esto cada 10 segundos....

MANOS A LA OBRA


Lo que habeis leido anteriormente parece un sueño, pero es perfectamente realizable. Tan solo basta con encontrar los elementos adecuados para hacerlo, que sea barato, y que sobre todo, tenga detrás a uno o varios equipos de trabajo dispuestos a crear la red necesaria para llevarlo a cabo. Como si de una receta de cocina se tratase, a continuación os doy los ingredientes para que el que se crea capacitado, lo pueda hacer. Yo ya lo he hecho, y no os puedo describir mi satisfacción. Por eso quiero compartir con vosotros este invento, si es que podemos llamarlo así. Esto es puro hobby y eso es lo que me gustaría que siguiera siendo. Lo que a continuación vais a ver, podría tener multitud de variantes... De eso se trata, de variar y mejorar...


INGREDIENTES:

LADO DEL CLIENTE (CLIENT SIDE)
1 decodificador con tarjetero y/o CAM. No sirven otros.
1 conexiòn a internet a través de ADSL
El circuito electrónico del que estamos hablando

LADO DEL SERVIDOR (SERVER SIDE)
1 Ordenador
1 interfaz PHOENIX TE-21
1 software que actue de server


Como vereis, en el CLIENT SIDE no es necesario un PC. Nuestro circuito electrónico lo hace todo: hablar con el deco, enviar por TCP/IP la ECM y recibir por el mismo método la DCW que, finalmente, será inyectada en el decodificador para que este decodifique la señal de video y podamos ver nuestros canales favoritos.

En el SERVER SIDE, yo pongo que es necesario poner un PC, pero si me apurais, ni eso...Podría existir un circuito electrónico similar al del CLIENT SIDE que hiciera las veces de SERVER y que se encargase de gestionar todas las peticiones que los CLIENTES hicieran.


Ahora bien...¿Y donde está ese circuito electrónico maravilloso”... A estas alturas, muchos de los lectores que estén medianamente familiarizados con las nuevas tecnologías estarán pensando ya en algo que pueda servir. Yo voy a poner un par de ideas y que seais vosotros los que os encargueis de elegir la más adecuada.


ANTES DE ELEGIR, ESTUDIAR

Circuitos electrónicos capaces de hacer lo que estamos pidiendo, hay algunos, pero se trata de elegir el más barato y fácil de programar. Y no estamos hablando de hacer un firmware para decodificar un sistema de encriptado determinado ni nada por el estilo. Se trata de un firmware que sea capaz de comunicarse con una CAM y que por el otro lado sea capaz de comunicarse por internet con un servidor. Ni más ni menos. Chupao.

Por un lado, está el tema de la comunicación con la CAM. Como muchos sabréis, la CAM trabaja con el protocolo ISO 7816-E que es el necesario para establecer una comunicación entre el decodificador y la tarjeta original. La existencia de los llamados SEASON, o loggers, nos da ya el trabajo hecho. En cualquier parte podreis encontrar circuitos electrónicos de cómo hacer un SEASON. Ya sabeis que el SEASON se conecta a un PC a través de un puerto serie RS232, pues bien, se trata de, en vez de poner en ese puerto serie un PC, pongamos nuestro microprocesador y que sea él el que se encargue de todo. Tan solo hay que procurar seguir a rajatabla el proceso de ATR de la tarjeta (ya sabeis, el famoso DCD o Data Carrier Detect) y el resto está hecho. Se trata de investigar, nada más. Yo me he dado muchos golpes antes de conseguir hacer funcionar el tema, pero al final, el premio es gratificante.

Por otro lado, está el tema de la comunicación remota con el servidor a través de internet. Entonces ¿qué circuito existe en el mercado que pueda hacer tal cosa?

Pues......ESTE:
[url]http://www.lantronix.com/device-net...vers/xport.html[/url]


...y si lo quereis wireless...ESTE:

[url]http://www.lantronix.com/device-net...ers/wiport.html[/url]




...o este:
[url]http://www.digi.com/products/embedd...giconnectme.jsp[/url]


...tambien en wifi, y más bonito:

[url]http://www.digi.com/products/embedd...connectwime.jsp[/url]


...o estos...
[url]http://www.zworld.com[/url]


Todos ellos, son módulos programables en C y tienen lo que se necesita: un UART y un stack TCP/IP...¿Qué más podemos pedir?

RESUMIENDO

El CardSharing es un tema apasionante y a los iniciados les recomiendo su estudio. Los módulos que os he indicado arriba son muy baratos (el más barato son 40 euros) y la electrónica necesaria para que funcione es mínima (alrededor de otros 3 o 4 euros).

O sea, que por, digamos, 60 euros, se puede tener todo un sistema de CardSharing y lo mejor de todo, aprovechando tu decodificador. ¿Qué más quieres?. Busca un electrónico y un programador y tendrás tu CardSharing System.

Ahora se trata de crear la red...la tela de araña que soporte este sistema...Pero eso será objeto de otro estudio.....

De momento lo teneis fácil. Buscaros un manual de cómo hacer un SEASON (aquí os pongo uno
[url]http://www.usuarios.lycos.es/doraim...20II%20LITE.zip[/url] ) y lo que teneis que hacer es conectar el puerto serie al del micro que vayais a usar. Sin MAX232 ya que son niveles TTL. Programais el micro y ya está.

Este documento no explicará como programar en C estos módulos. Ellos ya lo hacen en sus respectivos kits de desarrollo, pero lo importante es que tenemos a nuestro alcance todos los medios necesarios.

Animo que no es difícil. No se requieren conocimientos de sistemas de encriptación de TV digital, tan solo algunos conocimientos de lenguaje C y de electrónica...y tampoco muchos....


NOTAS PARA LOS QUE EMPIECEN

Quiero comentaros cuales han sido mis pasos y donde me he equivocado, así como las soluciones que he ido buscando hasta llegar el momento de tener el sistema totalmente operativo. De esta manera puede que os ayude a no cometer los mismos errores que yo he cometido, facilitándoos el trabajo y acelerando el proceso de producción.


CUESTION: ¿Cómo me comunico con la CAM?

La comunicación con la CAM es relativamente fácil, sobre todo cuando se sabe qué hacer y sobre todo qué no hacer. Lo que no hay que hacer es no perder la paciencia. Para ello hay que saber qué es lo que hace la CAM cuando nota que le han insertado una tarjeta en su interior. En primer lugar, diré que vamos a utilizar un puerto serie para hacer esta comunicación. Ese puerto serie es uno de los que tiene cualquiera de los micros que antes os he enseñado. La comunicación se realiza a 9600 baudios, paridad EVEN , 8 bits de datos y 2 bits de parada.
Cuando el decodificador detecta una tarjeta en su CAM (o en nuestro caso, nuestro circuito), le envía a esta una señal a través de su RTS al DCD que nosotros estaremos leyendo. Cuando el DCD baja, es la hora de enviar el ATR de la tarjeta. Este ATR puede ser el de una negra V7 cualquiera. En este momento, el decodificador comienza a hablar y es aquí cuando podemos hacer dos cosas: o seguir simulando que somos una tarjeta de verdad y entonces tenemos que añadir al código del microprocesador todo el tedioso proceso de reconocimiento (ver el SECAFAQ por ejemplo u otros documentos al respecto) o bien simplemente transmitimos esos datos que nos vienen del deco por internet hasta nuestro servidor, para que de esta manera se produzca un diálogo fluido entre la CAM y la tarjeta real que está al otro lado de internet. De lo único que se tiene que encargar el micro entonces es de mantener viva esa comunicación TCP/IP. Lo principal es indicar al decodificador de que tiene una tarjeta insetada en su CAM (esto se hace con el ATR ficticio) y lo demás es coser y cantar. Datos van, datos vienen. A nosotros nos dará igual lo que entre o salga. Entre el decodificador y la tarjeta remota se entienden. Si conseguimos hacer esto correctamente, todo lo demás estará hecho.
ADVIERTO: El proceso descrito donde interviene el DCD es crítico y por eso hay que prestar especial cuidado en él. Es quizás lo más crítico de todo. Indicar la importancia del DCD ya que estamos usando una comunicación SINCRONICA.

CUESTION: ¿Qué ocurre en el SERVER SIDE cuando llegan datos?

Suponiendo que el proceso anterior ha dado resultado, en el SERVER aparecerán los datos que el CLIENTE está enviando. Estos datos han de ir directamente a nuestra tarjeta original, a través del PHOENIX TE21 que hemos conectado a su puerto serie. Es necesario diseñar en el lado SERVER un software apropiado que gestione las conexiones y que se encargue de devolver a los CLIENTES la DCW tan ansiada. Con un sencillo programa en Visual Basic se puede realizar esta tarea.





CUESTION: ¿Son seguras las comunicaciones?

Pues obviamente no. Existe un proyecto de CardSharing a través de ICQ lo cual garantizaría la privacidad de las comunicaciones. Tü circuito no se conectaría directamente al SERVIDOR sino que lo haría a través de una sesión ICQ. Esto significaría que habría que programar en el microprocesador todo el protocolo de ICQ, cosa que es compleja pero que desde aquí animo a los que se atrevan a hacer una librería apropiada para ello.

CUESTION: ¿Cuántas sesiones simultáneas admite el sistema?

La respuesta es complicada. Depende de varios factores. Si usamos un PC en el SERVER SIDE, pues admite bastantes. Si usamos en vez de un PC, un microprocesador similar al que se usaría en el CLIENT SIDE, posiblemente bastantes menos. Se podría optimizar el proceso pero eso requiere investigación y perfeccionamiento. Yo animo a todos los que quieran colaborar a aportar su granito de arena. Este proyecto no es posible llevarlo a cabo sin la intervención de cuantos más mejor. El “timing” (proceso en el cual se encuentra involucrado el tiempo de respuesta) es crucial en estos casos, y una CAM que pregunte por una DCW puede no tener mucha paciencia si no se le responde en un tiempo relativamente corto (entre 1 y 2 segundos de media). Es decir, cuando la CAM envia la ECM, espera recibir la DCW pronto. Ese intervalo de tiempo que transcurre (el timing) es muy importante. Bueno, se trata de investigar ¿no?.

CUESTION: ¿Cuántos sistemas soporta este dispositivo?

De momento yo he hecho pruebas con SECA2. Mis recursos o mejor dicho, mi falta de ellos me impiden poder realizar otras pruebas con otros sistemas. Vosotros estais ahí para eso. El que quiera, ya sabe...Vais a divertiros de lo lindo, os lo aseguro.

CUESTION ¿Sirve un decodificador que no tenga CAM o tarjetero?

Pues no. Se trata de encontrar una manera de hablarle al decodificador, y eso solo se puede hacer por la CAM. Desconozco si existen decodificadores a los que pueda hablárseles por su puerto serie...No lo se. Si se pudiera, pues entonces se podría adaptar.


Podeis mandar comentarios a [email]gicateam@hotmail.com[/email]. No prometo contestar. Quizás seria interesante usar algún foro al respecto.







Un saludo y espero que le sepais sacar provecho a esta idea.


GICA: Grupo de Investigación de Cardsharing Alternativo"

sI ALGUIEN LO LEE COMO SE VERÁ ES MUY INTERESANTE.

¿y eso con el philips, pues he leido que ya gente lo va probando con exito relativo (solo en casa).

saludos.