[Cam Algemeen] CAM/card programmeren for dummies

[Gast]

Als er een de-scrambler in een FTA ontvanger zou (moeten) zitten, dan is het onzin als de hele stream door de CAM heen moet - alles wat de ontvanger echt moet weten is het controlword, dat descramblen kan hij zelf wel (het algoritme is altijd dezelfde).

 

Het zou dus logisch zijn dat een FTA stream een 'null' codeword heeft - het effect op de data is nihil. De FTA ontvanger hoeft niks met de stream te doen. Mocht de stream door een CAM gaan, ach, de-scramblen mag, dus geen probleem.

 

Hoe groot is een codeword eigenlijk? (20 bits is errug weinig - een PCtje kan die paar miljoen combinaties in 10 seconden best allemaal proberen)

[prutsie]

Een DVB chipset kan wel degelijk descrambelen, voorbeelden te over. Als je kijkt naar de diverse FTA ontvangers die niet over een CI slot of kaartlezer beschikken maar wel degelijk een gecodeerd beeld zichtbaar kunnen maken met de juiste emu en key maakt dit wel duidelijk.

Ook de Dreambox is een goed voorbeeld. Zonder CI module geinstalleerd maar met de juiste emu toch beeld. decrypted word kan van een kaart komen, of van de emu zelf mits de juiste sleutels aanwezig zijn.

 

Als je het DVB verhaal ook leest zie je dat een "common scrambling" algoritme wordt gebruikt. Hier overheen wordt gecrypt in Irdeto, Seca, Viaccess, etc.

 

Wat mij opvalt is dat de gehele datastroom door de CI gaat. Dat is nogal wat data. Ik neem aan dat alleen de datapackets van het gekozen kanaal door de demuxer naar de CI worden gestuurd, en niet de hele datastroom van de transponder, maar dan nog blijft het veel data.

 

Wat handig zou zijn om te weten is wat men nu precies codeert aan de data ? En hoe werkt het decoderen nu precies ? De processor van de CI moet toch wel donders rap zijn wil die een datastroom van minimaal 4Mb/s in relatime decoderen.

Dit is ook wat er bij mij niet ingaat. Dat de codering van de datastroom ingewikkeld is. Het moet een codering zijn die gemakkelijk en snel door minder snelle processoren kan worden bewerkt (gedecodeerd) zodat de decoder in de ontvanger er weer raad mee weet. Vergeet niet dat de techniek al een aantal jaren oud is, en dat er toen nog geen super rappe processoren waren.

 

weer genoeg stof tot nadenken,

groeten,

Peter.

[Zilverster]

@Hermanator,

 

Kunnen we de vraag waarschijnlijk ook nu wel hier stellen, ik hoop dat je er geen probleem mee hebt <img src="/ubbthreads/images/graemlins/shocked.gif" alt="" /> , je weet waar we het weekend aan zijn begonnen.

 

 

@All,

 

Even een voorbeeld, een programma als Wallbanger logd de gegevens. Deze worden netjes weer gegeven in een logfile als je hem opslaat op je harde schijf. Wat je ziet zijn de C1 3C, dan de C1 3A en niet te vergeten de C1 40 met natuurlijk de rest van de gegevens en de antwoorden van de kaart zoals bijv. 90 00.

 

Men neme de ruwe, rauwe log of hoe je het ook noemen wilt van de communicatie tussen cam en kaart, ik hoop dat jullie het nog kunnen volgen.

 

Dan nu de vraag, worden de uitkomsten zoals men die kan lezen in het programma Wallbanger, C1 3C, C1 3A, C1 40 en de antwoorden zoals 90 00 enz. omgezet door het programma Wallbanger en dus zo vertaald of wordt dit echt door C+ zo verzonden zoals men het leest in de log van het programma.

 

Ik weet dat het een moeilijke vraag is, maar kan het helaas niet beter omschrijven <img src="/ubbthreads/images/graemlins/blush.gif" alt="" /> , gr.

 

Zilverster.

[Gast]

@Milo,

 

Citaat:

Als er een de-scrambler in een FTA ontvanger zou (moeten) zitten, dan is het onzin als de hele stream door de CAM heen moet - alles wat de ontvanger echt moet weten is het controlword, dat descramblen kan hij zelf wel (het algoritme is altijd dezelfde).

 

Dat de hele transportstream door de CAM loopt heeft niets te maken met het al dan niet aanwezig zijn van een descrambler in de ontvanger. Het is gewoon de implementatie van de CI interface. Zodra de CAM zich heeft geïnitialiseerd en de ontvanger zich ervan heeft overtuigd dat het een DVB CAM is, laat de ontvanger de gehele transportstream door de CAM lopen. De controlwords worden niet door de CAM aan de ontvanger gegeven. Nooit. Als de CAM de ontvanger vraagt iets te descrambelen, dan doet de CAM alles zelf. ECM's filteren, decrypten en aan de hand van de controlwords descrambelen. Het is ook één van de vereisten dat er geen beveiligingsgevoelige informatie (zoals controlwords e.d.) over de CI interface mag lopen. Zo is het nu eenmaal ontworpen.

 

Citaat:

Het zou dus logisch zijn dat een FTA stream een 'null' codeword heeft - het effect op de data is nihil. De FTA ontvanger hoeft niks met de stream te doen. Mocht de stream door een CAM gaan, ach, de-scramblen mag, dus geen probleem.

 

De stream gaat door de CAM, zie boven. Maar inderdaad doet de CAM met een FTA zender niets. De ontvanger zal hem dat ook niet vragen. Bij de aanmelding geeft de CAM de CAID's aan die hij kan decoderen en dit zijn ook de enige zenders waarom de ontvanger aan de cam om descramble zal vragen.

 

Citaat:

Hoe groot is een codeword eigenlijk? (20 bits is errug weinig - een PCtje kan die paar miljoen combinaties in 10 seconden best allemaal proberen)

 

Die 20 bits is fout. Sorry. Ik heb het nog even nagezocht in http://www.duwgati.com/archive/Documentation/CAS-model.pdf en daar staat het het 60 bits is. Je hebt dus gelijk!

 

Verder laat het natuurlijk de vraag open of een FTA uitzending nu wel of niet gescrambled wordt verzonden. Even voor alle duidelijkheid: hij is niet encrypted met een codering. Maar de vraag is of ie unscrambled wordt verzonden, of dat hij wel wordt gescrambled, maar met "gratis" controlwords.. Ik zoek ook verder.

 

Hermanator

[Gast]

@Prutsie,

 

Citaat:

Wat mij opvalt is dat de gehele datastroom door de CI gaat. Dat is nogal wat data. Ik neem aan dat alleen de datapackets van het gekozen kanaal door de demuxer naar de CI worden gestuurd, en niet de hele datastroom van de transponder, maar dan nog blijft het veel data.

 

Voor een CAM wordt door de EN50221 specificaties de volgende eis gesteld:

 

"All interfaces shall support a data rate of at least 50 Mb/s averaged over the periode between the sync bytes of successive transport packets"

 

Dat lijkt dus ruimschoots toereikend voor de 4 Mb/s die kennelijk wordt doorgegeven. Ik ben daar nog niet zo in thuis.

 

Citaat:

Wat handig zou zijn om te weten is wat men nu precies codeert aan de data ? En hoe werkt het decoderen nu precies ? De processor van de CI moet toch wel donders rap zijn wil die een datastroom van minimaal 4Mb/s in relatime decoderen.

Dit is ook wat er bij mij niet ingaat. Dat de codering van de datastroom ingewikkeld is. Het moet een codering zijn die gemakkelijk en snel door minder snelle processoren kan worden bewerkt (gedecodeerd) zodat de decoder in de ontvanger er weer raad mee weet. Vergeet niet dat de techniek al een aantal jaren oud is, en dat er toen nog geen super rappe processoren waren.

 

In de CAM zit een ARM7 processor die onze firmware uitvoert. Daarnaast zit er echter een aparte descrambler chip in die totaal dedicated voor descrambling is. Daarnaast bewerkt hij natuurlijk niet de gehele stream, maar alleen de PES waarvoor om descrambling is verzocht..

 

En zoals gezegd, conform de CI interface specificaties en50221 loopt toch echt de volledige transportstream over de CI interface de CAM in en uit.

 

Denk er ook aan dat er in de ontvanger dan geen decodering meer plaatsvindt. De cam heeft al gedescrambled,dus de ontvanger hoeft dan alleen nog te demoduleren (of hoe het proces van een ongecodeerde mpeg afspelen dan ook mag heten).

 

En wat er nu precies wordt gedecodeerd staat in het stuk. Alleen de ecm's worden om de 2 tot 10 seconden decrypted (weinig data) en met een controlword wordt dus 2 tot 10 seconden mpeg stream descrabled (dedicated chip).

 

Let er alstjeblieft op dat ik hier niet de wijsneus loop uit te hangen. Ik heb de stukken bestudeerd en probeer de hierin opgedane kennis te toetsen aan jullie vragen. Als we er lekker over discussieren, maken we het samen volgens mij een stuk duidelijker!

 

Hermanator

[prutsie]

@Hermanator,

Je loopt wel de wijsneus uit te hangen, en je hebt er ook alle recht op ! <img src="/ubbthreads/images/graemlins/grin.gif" alt="" />

Petje af wat je tot nu toe boven water hebt weten te krijgen. Ik hoop dan ook zeker dat je doorgaat en je niet laat hinderen door "onkundigen" zoals ik.

De mensen die dit soort zaken onderzoeken en het uiteindelijk te weten komen houden meestal alles onder de pet. Ik ben dan ook dolblij dat jij je bevindingen deelt. Ik weet zeker dat een hoop mensen hier op den duur lol van gaan beleven.

 

succes,

Peter.

[Gast]

The Chips and CI Modules implements mostly the CSA Scrambling Algo, but the USA use a DES Scrambling for the TS , the SCM Worldcam support both Scrambling Modes. The FEC ( you all know it) is a Reed Solomon Scrambling for a even Power distribution in the Transponder, the Key is of course Public.

 

cu DrGalaxis

[Gast]

@zilverster,

 

Tja, ik weet dat nog steeds niet. De communicatie tussen CAM en kaart heb nog niet bestudeerd. Ik heb me vooralsnog alleen maar bezig gehouden met het gebabbel tussen CAM en ontvanger. Met de kaarten ga ik nu aan de slag.

 

Ik weet absouluut niet of Wallbanger bytes intepreteert voordat hij ze aan jou laat zien. Ik weet wél wat je ziet als je met een gewoon serieel programma als realterm ertussen gaat zitten. Als je de display mode op Hex zet, dan zie je in één lange sliert alle bytes die de season logt. Ik neem aan dat dit zowel bytes zijn die van de ontvanger/cam naar de kaart worden gestuurd als de terug gestuurde antwoorden. Dat is natuurlijk een stuk lastiger debuggen. Waar begint de boodschap van de cam/ontvanger en waar eindigt hij en begint het antwoord? Ik denk dat Wallbanger je daarbij helpt.

 

Sorry dat ik je daar nu niet mee kan helpen, maar ik beloof je als ik straks wat kennis heb opgedaan over de communicatie met de kaart, ik er dan nog eens naar zal kijken. Maar misschien dat iemand anders hier wat meer over kan zeggen?

[Gast]

@DrGalaxis,

 

Ik begrijp dat je hiermee duidelijk wilt maken dat Europa is gestandaardiseerd op CSA, en Amerika op DES?

Het is me alleen niet duidelijk of je hiermee reageert op je stelling dat een FTA uitzending unscrambled is?

Bedankt voor de input!

 

Hermanator

[Gast]

@DrGalaxis,

 

Citaat:

and an extra Info:

the b002 Chip is a TDA8002 from Philips

 

Bedankt ook voor deze aanvulling! Maar weet je ook de functie van deze chip in de Matrix? Ik heb de totale (samen)werking van alle (hardware)onderdelen van de CAM nog niet in beeld.

 

Tnx,

Hermanator

[Zilverster]

@Hermanator,

 

OK, is het geen geheim meer, soms is het ook moeilijk vragen stellen als je niet helemaal open kunt zijn. Het antwoord is hier boven al gegeven door Hermanator, realterm dus. Dit weekend ben ik eens gaan loggen met dit programma, de uitkomst allemaal vreemde waardes, heel anders dan dat je gewend bent met het programma Wallbanger, maar wel bepaalde overeenkomsten. Dus mensen die belangstelling hebben om het ook eens te proberen zijn van harte welkom. Op dit moment durf ik nog geen resultaten van een log te plaatsen omdat ik niet weet wat de uitkomsten zijn die gelogd zijn met mijn eigen originele Seca 2 kaart,dit i.v.m. serial en dat soort zaken. Ik weet dat de classe instructie voor een Seca kaart C1 is, het vreemde is dat dat in deze logs niet terug te vinden is even zo als de antwoorden van de kaart zoals 90 00. Hiervoor in de plaats staan totaal andere waardes. Nu zie ik e.e.a. als een ruwe/rauwe log, vandaar mijn vraag over de opbouw van een programma als Wallbanger en hoe gegevens verstuurd door de provider, gr.

 

Zilverster.

[Zilverster]

@All,

 

Nog even een kleine aanvulling :

 

Hieronder de eerste (aangepaste) regel van de log, waarbij opgemerkt dat :10 00 00 00 de nummer regeling van het programma is gevolgd door 16 byte's (aangepast door xx xx in dit geval) en waarvan ik de indruk heb dat de laatste byte (yy) ook nog bij de nummer regeling behoord. Het totale aantal byte's is 132 dus zonder nummer regeling van het programma maar wel inclusief de yy's.

 

 

:10 00 00 00 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx yy

 

 

Mijn eerste indruk is dat het pakketje van 132 byte's wel eens het C1 3C commando kan zijn waarna na een berekening de C1 3A komt <img src="/ubbthreads/images/graemlins/kweetniet.gif" alt="" /> , gr.

 

Zilverster.

[Gast]

TDA8002 is de smartcard interface chip.

 

Data sheet (html)

 

The TDA8002 is a complete low-power, analog interface for asynchronous and synchronous cards. It can be placed between the card and the microcontroller. It performs all supply, protection and control functions. It is directly compatible with ISO 7816, GSM11.11 and EMV specifications.

[Gast]

Datastroom van een transponder is ongeveer 44Mbps (megabit per seconde), da's dus zo'n 5 MB/s (megabyte per seconde). Dat is teveel voor een normale PCMCIA interface, dat is namelijk een ISA bus en die geeft het op ergens bij 2MB/s. Zeker als er ook nog gestreamd moet worden, gelijktijdige in- en output dus.

 

De CI interface speelt daarom vals: In "descramble" mode worden de adreslijnen als data input gebruikt, en de datalijnen als data output. Door deze truuk is de maximum datarate veel hoger, maar is de kaart niet meer een PCMCIA kaart. Vandaar dat een CAM kan wisselen tussen de gewone PCMCIA en 'descramble' modes.

 

44Mbps sluit ook goed aan bij de eis van 50Mbps - een hele transponder dus. De datarate van een transponder is trouwens constant, maar de datarate van een zender is dat niet (variable bitrate wordt gebruikt om meer zenders in dezelfde ruimte te proppen). In principe mag een zender een hele transponder beslaan. Dus zelfs als hij maar een zender hoeft aan te kunnen, moet hij toch in staat zijn een hele transponder te verwerken.

[Gast]

@MiLo:

the CI is a PCMCIA Card in 8 Bit Mode and the free 8 Adress and 8 Data lines are used for the TS Interface. So its no need to "switch"

The CI is always using the whole Transponder, because the whole Transponder is in the TS, only the PIDs are filtered. If you take a look on Pro7HD or Euro 1080, which are FTA btw. Irdeto2 scrambled HDTV with 20MBits or more, and the Euro1080 is decoded with a standard Irdeto CI.