[Cam Algemeen] CAM/card programmeren for dummies

[Gast]

Hier is dan versie 4 van het document met in hoofdstuk 5 een technisch ontwerp voor een emulatie. Gaat dit werken? Geen idee. De komende tijd ga ik proberen dit te programmeren en in de cam te laden. Ondanks dat ik niet zeker ben of dit gaat werken, heb ik het toch vast hier neergezet, zodat anderen hopelijk ook gaan proberen dit te programmeren. Misschien komen er nog ideeën voor verbeteringen hier.

 

Het ontwerp is aan de ene kant erg gedetailleerd, aan de andere kant zijn er nog wel een paar kleine punten die nog moeten worden uitgezocht. Ik heb deze niet in de documentatie kunnen vinden, dus dat zullen we proefondervindelijk moeten uitzoeken.

 

Ook heb ik geen exacte syntax gebruikt voor de beschrijving, om de simpele reden dat ik er geen ken. Ook mijn kennis van de programmeertaal C is momenteel nog te beperkt om een precieze formulering in deze syntax te doen. Ondanks dat sommige dingen wat vrij zijn omschreven, denk ik dat met de documentatie van en50221 erbij het voldoende is om te programmeren.

 

Ik hoop dat er weer een aantal van jullie bereid zijn zich in dit hoofdstuk te verdiepen. Vragen of opmerkingen zijn zoals altijd weer van harte welkom!

 

Succes!

 

Hermanator

771991-CAMprog4_0.pdf

[Gast]

Heel mooi...

 

Heb het nu erg druk met kerst, oud en nieuw, maar zodra ik wat tijd heb zal ik eens proberen een klein test progje te maken. Hoop dat anderen ook gemotifeerd raken en mischien een contributie kunnen en willen dragen aan een open source cam.

 

Suc6 to all.

 

Wildcard

[Gast]

Wel ik ben ook een nieuweling en moet zeggen dat uw handleiding wel het handigste is dat ik gevonden heb

Ga vooral zo verder <img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" /> <img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" /> <img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" />

[Gast]

In een buitenlands forum kreeg ik de vraag hoe en cam nu eigelijk met een decoder communiceert. Dit staat natuurlijk allemaal in het document beschreven, maar ik ga dat niet helemaal in het engels vertalen. Ik heb toen een compacte uitleg voor ze geschreven. Hoewel het in het engels is, is het misschien voor sommigen van jullie wel interessant. Het is eigenlijk een piepkleine samenvatting van mijn document en en50221.

 

Dus voor de liefhebbers:

 

A cam communicates with the IRD over the CI interface. This interface has been standarized, since producers of IRD's and CAM have to be able to independantly create their products, and still have them work together in your house. The description of this standard is EN50221.

A cam has two logical interfaces to the IRD: 1) the command interface and 2) the transport interface, both of them over the same physical pcmcia interface.

 

1) The transportstream flows over the transport interface. The cam can access the stream and filter ecm pid's, extract control words and descramble certain pid's. These packets are descrambled and given back to the IRD. Other packets are untouched, and returned as they are. If there are more cams in the IRD the transportstream is daisychained through them.

 

2) The command interface is for the communication between the cam and the IRD. Through this interface the cam can inform the IRD which CAID's it can descramble and the IRD can then request the cam to descramble a certain service, once selected by it's end-user. Also the menu-handling is done over the command interface.

 

The transport interface is not of our concern, while developing an emulation. Once initialized the datastream flows through our cam, without us programming something. For the Matrix, Sidsa has supplied standard api-calls you can use to filter pids, feed control words in the descrambler, etc.

 

Our work is the command interface. How does this work? For the communication they designed a model similar like the osi layers. Data flows from one side (the IRD) down these layers, over the interface to the other side, and there it flows up through the same layers until it reaches it's destination. Each layer add's adress information, splits up or concatenates packets, adds lengthfields, etc.

 

Over these layers applications (like our emulator) communicates with resources, which can reside as well on the host (the ird) as on the module (the cam).

 

The layers are (top-down): appliction layer, session layer, transport layer, link layer and physical layer. For the last one, api calls are supplied. The rest you have to program yourself. Each layer communicates with it's counterpart on the other side. Data received from it's own higher layer it reformats to its own packet type and hands it over to it's own lower layer.

 

This data is simply strings of bytes, which in the documentation are called objects. These objects have identifiers to indicate the packet type. The protocol (the way you communicate with a resource) is defined in the order in which objects have to be exchanged between the application and the resource. Each resource has it's own protocol. An example is the CA Manager. In your emulation you register with the CA Manager, telling it what you are able to descramble.

 

All this information can be found in EN50221. Understand this document, and understand iso13818 (description of the datastream) and with the right SDK and api calls you can develop an emulator!

 

Hermanator

[Gast]

Ontzettend hard gewerkt aan de ontwikkeling van de firmware. Met wat hulp van Italiaanse gelijkgestemden is het uiteindelijk gelukt!

 

Het gehele document is grondig herzien.

 

Om juridische redenen heb ik de doelstelling van de software veranderd van een emulatie in firmware zonder emulatie.

 

In de hoofdstukken 1 tot en met 3 heb ik aan de hand van de opgedane kennis een aantal zaken meer in detail en duidelijker omschreven. Naar aanleiding van de discussies die soms plaatsvinden over wat een CAM nu precies doet en of deze nu descrambling doet of niet, heb ik paragraaf 3.2 [color:"red"] “Wat doet een CAM nu precies” [/color] geschreven.

 

Het is dus zeker de moeite waard ook het eerste deel van het rapport dus opnieuw te lezen!

 

Verder heb ik hoofdstuk 5 met het technisch ontwerp totaal opnieuw geschreven. Hoewel keurig opgezet met een strikte scheiding tussen de verschillende layers, leidde de eerste versie (Eva_01) tot een programma van zo’n 1200 regels en een binary die alleen voor de verschillende buffers al meer dan 500 Kb vereiste. Het ontwerp is nu opnieuw, wat pragmatischer opgezet op basis van het door Sidsa gegeven voorbeeld voor communicatie met de pcmcia interface. Ontvangen objecten worden direct verwerkt en het totale aantal buffers is hierin van 8 tot 1 gereduceerd. Het ontwerp is ook wat globaler waardoor het kleiner is, en hierdoor ook vanuit een appendix verhuisd naar het hoofdstuk zelf.

 

Verder is hoofdstuk 6 Programmering geschreven en is de totale code van de firmware in appendix 5 opgenomen.

 

In appendix 6 is ter verduidelijking een log opgenomen van de communicatie tussen CAM en ontvanger.

 

Veel plezier!!

Hermanator

839922-CAMprog5_0.PDF

[prutsie]

Als ik het zo eens snel doorsnuffel ben je al een heeeel eind. Petje af voor dit zeer verhelderende epistel. Hoe het programma in elkaar steekt zal ik wel nooit begrijpen, hoe een cam werkt, en wat er gebeurt wel.

 

Zal vanavond in elk geval eens rustig verder gaan lezen. Ook voor dummies zoals ik is het meeste in duidelijke begrijpelijke taal geschreven.

Dank hiervoor.

 

groeten,

Peter.

[Zilverster]

@Hermanator,

 

<img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" /> Dan is het nu tijd voor een glaasje......., ik verheug me al op het vervolg <img src="/ubbthreads/images/graemlins/biggthumpup.gif" alt="" /> , gr.

 

Zilverster.

[Gast]

Volgens mij iemand met een opleiding als programmeur kan er zo mee aan de slag ik heb het ook weer van het begin gelezen, maar om een heel oude diskussie weer op te rakelen waarom ontwikkelen ze niets om het gecodeerde signaal er af te halen voor dat het de ontvanger binnenkomt.

 

Zou de doodsteek zijn voor alle providers en iedereen zou aan een FTA ontvanger genoeg hebben.

 

Groetjes <img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" />

[Zilverster]

@aart44,

 

Ja, wat dacht je <img src="/ubbthreads/images/graemlins/grin.gif" alt="" />, gr.

 

Zilverster.

[Gast]

Citaat:

@aart44,

Ja, wat dacht je <img src="/ubbthreads/images/graemlins/grin.gif" alt="" />, gr.

Zilverster.

Ja volgens mij moet het mogelijk zijn maar met failliette providers heb je nog niets dus het zal wel een moeilijke materie blijven.

Groetjes <img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" />

[Gast]

Voor mij is dat geen oude discussie hoor, zolang ben ik nog niet op sat4all. <img src="/ubbthreads/images/graemlins/smile.gif" alt="" />

 

In theorie zou het wellicht mogelijk zijn, maar ik denk dat het daar net iets te ingenieus voor in elkaar zit.

 

Iedere uitzending kan, ongeacht de codering, worden bekeken als je de controlwords hebt. Het enige verschil tussen de verschillende coderingen zit hem alleen maar in de manier waarop de controlwords worden versleuteld. Als er een superintelligent programma zou zijn, dat altijd de controlwords weet te decrypten, geven alle zenders altijd beeld. Alle overige zaken zoals EMM's met abonnementsgegevens, NANO's, etc. zouden dan totaal niet interessant meer zijn.

 

Gezien het feit dat een controlword uit 20 bits bestaat, en wordt versleuteld met per CAID verschillende algoritmes, sleutels, hashtables en andere trucs, heb ik daar echter weinig hoop op. Het beste dat men ooit bereikt heeft is dat een encryptie zover bekend is dat men een AU emulatie heeft kunnen programmeren. En dat is bij de recentere encrypties al niet meer het geval.

 

Het wordt ook alleen maar erger. Encrypties zullen sterker worden dan de hackers zullen kunnen kraken vrees ik. Is bijvoorbeeld pgp te kraken?

 

De enige kans op wat gratis beeldmateriaal is het bekend worden van wat keys en hashtables bijvoorbeeld, waardoor we weer even beeld hebben. Een andere kans zit hem in het kraken van de smartcards, waardoor deze daadwerkelijk gedupliceerd kan worden. Zolang de providers niet weten welke kaarten gedupliceerd zijn, kunnen ze daar denk ik weinig aan doen. Maar ook dat is nog niet gelukt, althans voor zover ik weet.

 

Cardsharing over internet is een andere optie, maar daar geld hetzelfde voor. Eenmaal ontdekt gaat de kaart op zwart. Bovendien denk ik dat daarvoor wel degelijk technische tegenmaatregelen zijn te bedenken. En dat zullen ze dan wel doen ook! <img src="/ubbthreads/images/graemlins/smile.gif" alt="" />

 

En ach, het is toch ook helemaal goed zo? Net wat je zegt, wat heb je aan failliete providers? Dat zijn ook gewoon bedrijven die inkomsten nodig hebben om producten te kunnen leveren. Alleen over de prijs-prestatie verhouding zou je kunnen discussieren.. Naarmate zwartkijken eenvoudiger zou zijn, zou deze vorm van diefstal ook niet meer zo onschuldig zijn en echt levensbedreigend voor hen worden.

 

En ook voor ons is het toch leuk dat het allemaal zo lastig is? Dat is voor ons toch juist de hobby, om te doorgronden hoe het allemaal werkt? Laat dus maar lekker zo! Ik vind het veel te leuk om zo met jullie samen te werken!

[Gast]

Genial!!

 

and an extra Info:

the b002 Chip is a TDA8002 from Philips

[Gast]

De grootste angst is "stream attack" - dat lijkt op wat Aart voorstelt.

 

In plaats van de codering ga je het codeword zelf proberen te vinden.

 

Simpele methode is brute-force: "allemaal uitproberen tot je er eentje vindt die werkt". Je hebt 2 tot 10 seconden de tijd als je real-time wilt kijken. Je kunt de stream ook op een harddisk opnemen en je PC er een jaartje op laten zwoegen om alle benodigde controlwords te vinden. De film gewoon huren is natuurlijk goedkoper - maar hobbies kosten nou eenmaal geld.

 

Een andere methode is de random-generator aanvallen. Eentje zoals je in Basic of de standaard C library cadeau krijgt is niet random genoeg - na een paar miljoen waardes valt hij in herhaling. Je kunt die reeks in een flashgeheugen programmeren (of in een processortje als je het algoritme toch al weet) en dan kun je de controlwords zelf heel makkelijk vinden.

 

Op den duur zijn onze computers misschien snel genoeg voor een real-time brute-force attack op de stream. Dat is dan het einde van de huidige DVB standaard, en dan komt er wel een nieuwe.

[Gast]

A Error n Page 6:

Bij een )7$)UHH7R$LU uitzending die iedereen dus vrij mag ontvangen, worden de controlwords

unencrypted in ECM’s verzonden. Iedere DVB ontvanger is dus in staat om de controlwords uit de ECM’s te

halen en het betreffende programma te descrambelen. Ook een FTA ontvanger heeft dus wel degelijk een

descrambler. Alleen is een FTA ontvanger niet in staat om een encrypted ECM te ontsleutelen.

An FTA Sender is NOT scrambled, and not all chips have a descrambler, see the Budget PCI cards.

 

cu DrGalaxis

[Gast]

Kijk, eindelijk eens leuk inhoudelijk commentaar op de inhoud!!! (niet dat de bedankjes niet welkom zijn hoor! <img src="/ubbthreads/images/graemlins/xyxthumbs.gif" alt="" />)

 

Ik had de oorspronkelijke conclusie dat een FTA uitzending tóch gescrambled wordt uitgezonden, maar met unencrypted controlwords, afgeleid uit de DVB stukken die ik heb gelezen. Daar stond namelijk in dat de uitzendingen niet alleen voor bescherming worden gescrambled, maar ook om storingen van het satelietsignaal te voorkomen.

 

Later heb ik daar met verschillende mensen over gesproken. De één zegt dat het inderdaad zo is, de ander dat een FTA uitzending echt niet wordt gescrambled en dat een FTA ontvanger ook geen descrambler heeft. De volgende beweert weer bij hoog en laag dat een FTA ontvanger wel degelijk ook een descrambler heeft, omdat hij moet voldoen aan de DVB normen. Er zou alleen geen smartcardreader en decryptie ondersteuning in zitten. Voor mij dus inderdaad ook nog een onzeker punt.

 

Ik heb er tot op heden nog niets hards over kunnen vinden in de diverse documenten die ik heb. Misschien dat jouw verwijzing me wat meer info kan opleveren. Ik ga ermee aan de slag. Bedankt!!