[Cam Algemeen] CAM/card programmeren for dummies

[IceKiller]

braindamage de 5 is de laatste...

 

vroeger werkte het zo eerst werd een MOSC, officiele kaart die software matige aangepast is, waardoor je vb meer kanalen kon krijgen of verlengen... (meer over te vinden @ duwgati)

 

daarna de funcards die eigenlijk zorgde zodat je geen legale kaart meer nodig had maar moes je nog altijd updaten;; voordeel van funcards is dat je meerdere pakketen te gelijk open kon doen.

 

MR = matrix revolution cam

 

momenteel is S2 ( algoritme! keys wel..) nog niet uit te lezen of nog niet bekend.. daarom kunnen we weinig doen met de keys (hoewel er een seca 2 twister uitgekomenis dat een verlopen s2 kaart gebruikt en een andere kaart voor de nieuwe codes uit te lezen).

 

CAM's sturen pakketjes door naar de kaart.. de controlwordsworden doorgestuurd naar de kaart die dan sleutels maakt, die het beeld decoderen (dat doet de cam dus het beeld decoderen, de kaart geeft enkel de sleutel verwerkt na het algoritme).

[Gast]

Tot mijn kennissenkring behoren ook elektrotechnici (ben zelf meer een software-ICT'er). Dat plan van MiLo (lees je mee? <img src="/forums/images/graemlins/wink.gif" alt="" />) is volgens hen ondoenlijk, daar EEPROM's circa 10000 rewrites aankunnen... Per bit gaat dat neem ik aan... Vandaar maakt de schrijfsnelheid ook niet erg veel uit, EEMPROM's zijn bedoeld om sporadisch wat software/data op te slaan, geen real-time logs.... Hoe dan ook wel een origineel idee.

 

Als je control words naar de smartcard stuurt waarop die vervolgens de respectievelijke keys uitvoert (gaarne meer informatie over de lengte etc. van die keys, ik heb het document nog niet helemaal gelezen hoor), kun je toch alle mogelijke control words genereren en die telkens door de smartcard heenhalen? De enige bron van entropie is volgens mij de tijd (voor zover die wordt bijgehouden in de smartcard). Als je de smartcard telkens op een of andere manier reset zodat hij geen onderscheid kan maken tussen het ene moment en het andere, en telkens na iedere reset één van een uitputtende lijst control words doorvoert en zodoende een key uit laat voeren, kun je aan de hand van de lijst met keys het algoritme van de encryptie bepalen. Hoeveel bits is die processor in een officiele smartcard overigens? Ik neem aan 8 of hooguit 16-bits.... En hoeveel registers heeft die processor (aangenomen dat er uberhaupt sprake is van cache)? Een control word is 60-bits, in het waarschijnlijke geval dat de entropie in de uiteindelijke keys slechts verwerkt is in de vorm van een waarde niet groter dan 16 bits en de key in lijn met ditalles 76-bits lang is, is de entropie na 65.535 gegenereerde keys niet langer willekeurig meer (kan namelijk worden voorspeld)... Alleen dan moet natuurlijk nog uitgevogeld worden hoe deze in de 76-bits lange key verwerkt is... Maar als je die 65.535 keer een key genereert met een vaste control word, (liefst allemaal nullen i.v.m. mogelijk misleidend toegepaste rekenkunde) zou je alsnog het eerste puzzelstukje moeten hebben.

 

Hierna kun je het 'echte' onderliggende algoritme bepalen door achtereenvolgens alle mogelijke control words door je smartcard te voeren, de keys te ontleden (wat op dat moment inhoudt: de entropie verwijderen, oftewel het enige semi-willekeurige eraan).

 

Wellicht hebben ze de entropie en de uitkomsten van het algoritme rekenkundig door elkaar gehusseld, bijv. met een hash-functie, dat zou het lastiger maken want dan heeft de entropie geen duidelijk eigen bitposities meer (wat op zich ook wel waarschijnlijk is, daar de control words eenvoudig te loggen zijn heb ik begrepen, en zo wel heel eenvoudig de entropie onderscheiden zou kunnen worden). Volgens mij moet je dan de methode volgen dat je de smartcard telkens 'reset' en zonder meer alle mogelijke control words (bijv. oplopend) doorvoert teneinde een corresponderende key uit te laten voeren...

 

BTW, je kunt tegenwoordig voor een prikke wat rekenkracht op een supercomputer afhuren. Zie daarvoor: http://www.sun.com/service/sungrid/SUN_Grid_Datasheet_20054.pdf . Hoeveel rekenkracht anders dan 'enorm' dat is kan ik niet achterhalen...

[Gast]

De smartcard logger is bedoeld voor "software" logging, dus debuggen enzo (als je tuner te ver van de PC af staat). Niet om alle dataverkeer op te slaan.

Huidige status: Ik vecht nog met het zenden van de juiste ATR.

 

Een FUN kaart heeft een 8-bit processor aan boord. Maar rekenen (optellen, aftrekken, vermenigvuldigen etc) met 64 of zelfs 128 bits, dat lukt op een 8-bit CPU ook hoor. Dus de entropie van de control words zal heel dicht bij die 60 bit blijven.

 

Als je een CPU hebt die 1 miljoen keys per seconde kan 'uitproberen', dan doet hij er ongeveer 10.000 jaar over om alle 2^60 mogelijkheden te proberen.

 

Omgekeerd - je moet een controlword in 10 seconden vinden - dan heb je dus ongeveer een miljard van die CPUs nodig om beeld te houden.

[Gast]

Citaat:

De smartcard logger is bedoeld voor "software" logging, dus debuggen enzo (als je tuner te ver van de PC af staat). Niet om alle dataverkeer op te slaan.
Huidige status: Ik vecht nog met het zenden van de juiste ATR.

Ik las iets van enkele honderden bytes per seconde dat er geschreven kon worden naar de EEPROM van je smartcard. 10.000/100 = 100 seconden onafgebroken (over)schrijven en je EEPROM is statisch geworden... Natuurlijk, je had het al over buffering, maar ondanks dat het langer duurt is er geen wezenlijk verschil met het principe.

Citaat:

Een FUN kaart heeft een 8-bit processor aan boord. Maar rekenen (optellen, aftrekken, vermenigvuldigen etc) met 64 of zelfs 128 bits, dat lukt op een 8-bit CPU ook hoor. Dus de entropie van de control words zal heel dicht bij die 60 bit blijven.

Daarom ook: heeft die CPU nog registers (en van welke capaciteit?)? Het spijt me dat ik het laatste document niet goed heb doorgenomen, ik heb het nogal druk maar ben zeker geinteresseerd (getuige m'n theorietjes <img src="/forums/images/graemlins/wink.gif" alt="" />). Echte berekeningen via CPU-instructies met operands (oftewel parameters met een vastgestelde, toegestane grootte in bits volgens de specificatie van die CPU) die eigenlijk kleiner zijn dan hetgeen je nodig hebt (bijv. iets als "SUB 0xFFFF, 0xFFFF" terwijl je eigenlijk 0xFFFFFFFF minus 0xFFFFFFFF wilt berekenen - de inefficientie en gelijke uitkomst van dit voorbeeld daargelaten) worden bij mijn weten nauwelijks toegepast wegens de enorme inefficientie (meerdere instructies + extra overhead om berekening te doen slagen). Het kan wél zijn dat dit in de embedded computing wereld (soms) anders is....

Citaat:

Als je een CPU hebt die 1 miljoen keys per seconde kan 'uitproberen', dan doet hij er ongeveer 10.000 jaar over om alle 2^60 mogelijkheden te proberen.

Je bedoelt 1 miljoen control words per seconde, denk ik. Immers, de keys worden gevormd op basis van die control words. Wel zal deze strategie inderdaad heel veel keys opleveren, een aantal gigabytes vrees ik. Maar als we de entropie verslaan - wat op het eerste gezicht een veel eenvoudiger opgave is - kunnen we de keys verkregen uit logging ontleden.

Citaat:

Omgekeerd - je moet een controlword in 10 seconden vinden - dan heb je dus ongeveer een miljard van die CPUs nodig om beeld te houden.

Ik wil ook niet real-time ontsleutelen, gewoon het algoritme analyseren zodat je de gegevensstroom uiteindelijk wel real-time kunt 'ontsleutelen', zij het in een handomdraai.

Is het trouwens geen optie om een patentenbureau langs te gaan om te kijken of er iets over SECA2 is gedeponeerd? <img src="/forums/images/graemlins/loldev.gif" alt="" />

P.S.
Toegankelijke uitleg over de encryptie die naar verluidt toegepast wordt in SECA2: http://mathcircle.berkeley.edu/BMC3/rsa/rsa.html

[Gast]

@Hermanator:

 

Ik zou graag willen weten uit welke hardware de officiele Canal+-kaart bestaat (zo gedetailleerd mogelijk dan he)... Dus vandaar zie ik een nieuwe revisie van je document met enthousiasme tegemoet... Ik wilde nog wat andere vragen (niet over de encryptie etc.) stellen, maar ik ben die ondertussen al weer een beetje kwijt vrees ik. <img src="/forums/images/graemlins/crazy.gif" alt="" /> Dat krijg je ervan he? <img src="/forums/images/graemlins/wink.gif" alt="" />

[Gast]

Uit de trage reactie zul je waarschijnlijk al begrijpen dat het de laatste tijd niet zo heel snel met mij meer gaat. Door omstandigheden kan ik per week echt nog maar een paar uurtjes aan de hobby besteden, terwijl dat een paar maanden geleden nog een paar uurtjes per dag was. Maar, ik ben nog wel bezig en ik zal ook wel weer wat meer tijd beschikbaar krijgen. Voor de volgende versie van het document moet je dus nog eventjes geduld hebben, vrees ik.

 

Ik weet ook niet of die versie een antwoord gaat geven op de door jou gestelde vragen. Ik ben toch hoofdzakelijk software geörienteerd, en heb minder verstand van hardware. Ik focus mij dan ook veel meer op de werking van DVB en zodra ik met een kaart kan communiceren, ben ik meer bezig met wat dat voor mogelijkheden geeft, dan dat ik me verdiep in het type processor of de hoeveelheid geheugen. Milo heeft daar veel meer kaas van gegeten dan ik. Zodra ik maar weet hoe ik met hardware communiceer en het kan laten doen wat ik wil, vind ik het eigelijk wel best...

 

De status bij mij is dat ik heb voortgeborduurd op de code zoals ik die heb gepubliceerd. Die code is momenteel een rommeltje van allemaal half of niet werkende routines om het filteren van ecm's en emm's uit de transportstream te testen en de communicatie met de smartcard op gang te brengen.

 

Als ik beide aspecten goed werkend heb, dan zal ik de code moeten oppoetsen, en van het nodige commentaar voorzien. Doelstelling van de volgende versie is dat deze correct werkt met een officiële kaart, zodat je eens leuk in de code kunt kijken om te zien hoe dat in zijn werk gaat. Hoe ecm's worden vertaald in commando's naar de kaart en hoe de descrambling kan worden aangestuurd met de verkregen controlwords. En hoe de abonnementsgegevens in de emm's uiteindelijk aan de kaart worden doorgegeven. Ook wil ik in dezelfde firmware de mogelijkheid van logging opnemen, zodat je naar keuze ecm's, emm's en/of ci communicatie kunt loggen via een season interface.

 

Als ik dat dan goed werkend heb, dan zal ik mijn bevindingen en de uitleg weer verwerken in de volgende versie van mijn documentje. Kan dus nog wel even duren <img src="/forums/images/graemlins/grin.gif" alt="" />

[alx]

Traag of niet; never give up, pls.

[Gast]

Bij het spelen met de smartcards liep ik tegen een probleem aan dat dit deel van de software wel werkte met een oude seca1 kaart, maar niet met een nieuwe seca2 kaart. Ik kreeg die kaart maar niet geopend.

 

Na wat debuggen bleek dat de variabele ATRLength bij een seca1 kaart de waarde 16 teruggaf en bij een seca 2 kaart 17! Omdat de atr was gedimensioneerd op een lengte van 16 bytes gaf dit een overflow error. Het gekke is dat de variabele atr toch gewoon 16 bytes bevat, waarvan de laatste twee netjes 90 00 zijn.

 

Ik heb het zelf opgelost door eenvoudigweg de define van de variabele SCARDs_ATR_VALID nog van een extra 0x00 te voorzien aan het eind. Beide kaarttypen worden dan herkend.

 

Het ontbreekt mij nu even aan tijd wat dieper in de oorzaak van dit vreemde fenomeen te duiken, maar misschien scheelt het degenen die hier ook per ongeluk over struikelen wat tijd.

[Gast]

Hoi Herminator,

 

ik heb nog een oude Matrix Reloaded en wil graag je Firmware erop zetten. Maar er zijn nog enkele vragen:

 

1. Moet ik de xilink van de MM laden of is die von de MR voldoende?

2. Moet er een loader (Dreamload) erop? Ik heb een CAS2. Denk dat het niet nodig is.

3. Ik zie uit uw firm dat u de mmcorelibs gebruikt. Deze heb ik gevonden maar geen Makefile. Dat makefile van de magic-SDK gebruikt alleen een lib sdk.a en daar zijn de corefunkties niet in. Ik ken een beetjs van C en van een Makefile onder UNIX, maar heb geen idee van "crosscompiling", scatter, Flash enz. Kun je a.u.b een werkende makefile in je dokumentatie opnemen? In de meeste programmeerguids moet je eerst een "Hello World" programmatje tot werkend krijgen om zeker te zijn dat je proggrammeeromgeving (path, makefile, compiler, linker,...) ok is.

 

Zo te zien ben ik geen nederlander maar ik hoop dat het toch wel duidelijk is.

 

Groetjes en "never give up" <img src="/forums/images/graemlins/xyxthumbs.gif" alt="" />

travera74

[Gast]

Hallo,

 

Wat is het stil hier...

Is het gedaan met deze thread? Of heb ik iets gemist?

 

Ik ben helemaal nieuw hier, heb vandaag deze hele thread, inclusief de docs van Hermanator door zitten lezen (achter elkaar, wat een mooi stuk werk) en ben een heel stuk wijzer geworden vwb. de stand van zaken van de techniek voor conditional access.

 

Of is het mogelijk zo stil omdat er andere methodes om een CAM te emuleren in software (bv. soft-cams op een linux-box?) mogelijk zijn geworden?

 

Het is net of je het einde van een spannend boek niet hebt gelezen....

 

 

Henry.

[gigantaandemuur]

Citaat:

Het is net of je het einde van een spannend boek niet hebt gelezen....

 

Word i.d.d tijd dat de hermanator weer tijd heeft.gr

[Gast]

Ik heb nu toevallig wat vriendjes uit het noorden op bezoek die me erop wezen dat er berichtjes voor me stonden hier op sat4all. Ik heb privé en zakelijk een heleboel voor mijn kiezen gekregen het afgelopen half jaar. Totaal geen tijd voor de hobby gehad. Maar ik heb een hekel aan onafgemaakt werk. Hopelijk kan ik binnen afzienbare tijd de hobby weer oppakken en het stuk afmaken! Sorry guys!!

[Gast]

Succes Herman, ik zal je werk weer volgen hier. <img src="/forums/images/graemlins/xyxthumbs.gif" alt="" />

[gigantaandemuur]

Citaat:

Hopelijk kan ik binnen afzienbare tijd de hobby weer oppakken en het stuk afmaken! Sorry guys!!

Geduld is een schone .groetjes

[alx]

Sterkte en ik zie je berichten graag tegemoet!