Anti cascading en cw cycle check begrippenlijst ?

[bennieboy]

Hallo heren.
Leek me het beste om de vraag hier te stellen omdat er hier genoeg experts zitten die dat vast wel begrijpen

Probeer oscam te leren begrijpen, ben met testen bezig (intern)
Maar de vraag gaat dus puur om het te kunnen begrijpen.

Wat ik nu dus probeer te begrijpen wat de functie's van anti cascading inhoud,

En cw cycle check.

Wat ik zover weet is dat anti cascading een telling doet ? En als er teveel aangevraagd wordt dan geeft deze dus een valse ecm door ?
En wat ik van cw cycle check zover begrijp is dat deze de cw's die niet meer geldig zijn eruit filtert ?
Gaarne bevestigen of deze theorie klopt..

Maar waar ik dus graag een begrippenlijst over zou willen hebben wat deze optie's allemaal inhouden.
Met anti cascading.

Numusers:
Sampletime:
Penalty:
AClogfile:

Fakedelay:
Denysamples:

Met cw cycle check.

Max cycle list entries:
Keep cycletime:
On bad cycle:
Drop old CW:
Sensitive new CW:
Allow bad cycle from fixed Fallback:

Wat houd b.v. numusers en sampletime in ?
En max cycle list entries ?

Zou fijn zijn als iemand dit aan me kan uitleggen
Of een soort van begrippenlijst erover aan me kan geven wat het inhoud en wat het doet.
Dank u

[Codx]

anti-cascading is bedoeld zodat clients de kaarten niet verder kunnen doorsharen. Hij doet dit door het aantal aanvragen die een user kan doen te beperken. Heeft dus niks met de anti-cs te maken.

 

cwcyclecheck controleert of de cw's om en om herhalend zijn (normale situatie) en als dit niet het geval is dan kun je die afwijkende blokkeren. (let wel, de kaart heeft hier niks aan want de ecm is al verwerkt en geteld)  Stel een kaart gaat in anti-cs dan ga je van een herhalende cw naar een niet herhalende (versleutelde) cw maar het probleem is dat als de volgende cw ook weer versleuteld is dan is die wel weer herhalend zijn zal de cwcyclecheck niks opmerken.  Kortom die CWcyclecheck kan alleen wat met de overgangen.

 

Wellicht dat je er met andere pakketten wel wat mee kan maar voor canaldigitaal weinig.

6 oktober 2013 aangepast door Codx

[bennieboy]

Dat van anti cascading begrijp ik.
Alleen dat van cwcyclecheck zit er nog niet helemaal in.
Moet bij mij ook af en toe in "jip en janneke" taal uitgelegd worden

Maar goed met cw cycle check kan je dus afwijkende cw's blokkeren ?
En wat jij dus bedoelt ? Als een kaart in straf gaat dan blijft deze cw's afgeven alleen dit zijn valse ?
En dat wordt dus niet opgemerkt in de cwcyclecheck ?

Wat bedoel je met CWcycle check kan alleen wat met de overgangen ?
Kan je misschien op een makkelijke manier uitleggen wat voor overgangen ?

Dank u

[deeejeee]

ben hier ook wel benieuwd naar

7 oktober 2013 aangepast door deeejeee

[DoeEensGek]

Cw cycle check is juist handig voor CDnl pakketten. Heb je 2 of meer cdnl kaarten, en cycle check staat aan, dan zal hij elke cw om en om checken. Zit er een foute cw tussen die niet overeenkomt, accepteert dvbapi die niet en zal hij de ecm vragen aan de andere kaart, komt daar de ecm wel van overeen dan laat hij die door. Je instellingen moeten dit wel toelaten natuurlijk .

[Codx]

@DoeEensGek, nee dat is niet waar. De cwcycle check controleert alleen de cw's die kaarten afgeven, wat jij bedoeld is een vergelijking check tussen meerdere kaarten/cw's maar dan moet je sowieso de aanvraag (ecm) naar meerdere kaarten tegelijk sturen maar dat is toch juist niet wat je wil.

 

@bennybox ik zal het proberen uit te leggen.. normaal stuur je om de 10 sec een ECM (electronic counter message) naar de kaart, die antwoord dan terug met een CW bestaande uit 2 gedeeltjes.. de cw0 en cw1, die zijn als alles normaal werkt altijd om en om herhalend zoals je hier onder kunt zien.  het zijn fictionele cw's overigens

 

11:20:08 ecm aanvraag -> cw response: 67018098F170B91A   25B6A7855FACF972

11:20:18 ecm aanvraag -> cw response: 289D7F4A6FC0D434  25B6A7855FACF972

11:20:28 ecm aanvraag -> cw response: 289D7F4A6FC0D434  800AA336EAE3FCC9

11:20:38 ecm aanvraag  ->cw response: CA7F3C957FE694F9  800AA336EAE3FCC9

 

Op het moment de kaart nu in anti-cs gaat zal er het volgende gebeuren

 

11:20:08 ecm aanvraag -> cw response: 67018098F170B91A   25B6A7855FACF972

11:20:18 ecm aanvraag -> cw response: 289D7F4A6FC0D434  25B6A7855FACF972

11:20:28 ecm aanvraag -> cw response: 289D7F4A6FC0D434  800AA336EAE3FCC9

11:20:38 ecm aanvraag -> cw response: 69732CF3447382329  8C36D29A8DB4327D  

 

Zoals je ziet die laatste cw0 en cw1 wijken af en is daardoor niet meer herhalend. De CWcheck zal dit opmerken en als je wilt de CW blokkeren. Goed zou je denken. Het probleem is echter dat als de kaart in anti-cs blijft staan de volgende CW weer wel herhalend is, dat zie je in het volgende plaatje en dan heb je toch geen beeld.

 

11:20:08 ecm aanvraag -> cw response: 67018098F170B91A   25B6A7855FACF972

11:20:18 ecm aanvraag -> cw response: 289D7F4A6FC0D434  25B6A7855FACF972

11:20:28 ecm aanvraag -> cw response: 289D7F4A6FC0D434  800AA336EAE3FCC9

11:20:38 ecm aanvraag -> cw response: 69732CF3447382329  8C36D29A8DB4327D

11:20:48 ecm aanvraag -> cw response: 0267235AB23632214  8C36D29A8DB4327D

 

 

Kortom hij is herhalend wanneer de kaart normaal functioneert en hij is herhalend wanneer de kaart permenent zwart staat want de cw's zijn dan continue versleuteld. Op het moment een kaartje uit de anti-cs komt gebeurt weer percies hetzelffde. Van versleutelde cw's ga je dan naar normale cw's... dat bedoel ik met de overgangen.

[DoeEensGek]

@DoeEensGek, nee dat is niet waar. De cwcycle check controleert alleen de cw's die kaarten afgeven, wat jij bedoeld is een vergelijking check tussen meerdere kaarten/cw's maar dan moet je sowieso de aanvraag (ecm) naar meerdere kaarten tegelijk sturen maar dat is toch juist niet wat je wil.

Je zit er totaal naast codx... cw cycle check zit bij de user, NIET de reader. Hij checkt de cw's voordat voor dat de user (dvbapi) ze krijgt. Is de cycle oke komen ze bij dvbapi... zijn ze fout kan je instellen wat je wilt, http://www.streamboard.tv/wiki/OSCam/en/Config/oscam.conf#cwcycle_onbad .  Zo makkelijk is het.

Het is een groot voordeel voor als je meerdere kaarten hebt bij cdnl, mocht er een foute cw van een van je kaarten komen, accepteerd cw cycle check dit niet en vraagt oscam een andere kaart, Je behoudt beeld!

[Codx]

Nee DoeEensGek, helaas...

 

Allereerst het zit wel degelijk bij de reader en niet bij de user. (zou ook niet eens kunnen)  En de dbv-api is een client die gebruik je niet bij servers alleen op de box zelf.. Sowieso veroorzaak die dvb-api een hoop ellende en raad ik het gebruik er van af.

 

Ten 2e ik heb net uitgelegd aan de hand van logs dat het hele cwcycle systeem niet werkt voor de anti-cs alleen op overgangen. En oscam stuurt ecm aanvragen richting alle readers  maar dat wil je niet want je verspeelt zo slots op al je kaarten. 

 

Tevens de cwcycle check kan helemaal niet triggeren dat er opnieuw wordt gevraagd. Dan doet de client zelf (in jou geval dvb-api)  maar dan nog is het geen gewenste situatie want je stuurt zo opnieuw een ecm naar de kaart(en) waardoor de kans groter wordt dat ze boven de limiet uitkomen. Kortom je graaft je eigen graf.

 

Het idee was leuk maar de cwcycle check hebben wij niks aan.  De reden waarom kaarten in anti-cs gaan ligt in de hoeveelheid ecm's of afwijkende ecm's en daar doet de cwcyclecheck niks mee want dat is achteraf. En het gevolg kan de cwcyclecheck niet uitfilteren, alleen op de overgang van beeld naar geen beeld of geen beeld naar beeld want dan is er een verschil meetbaar.

 

Duidelijker kan ik het niet maken voor je.

7 oktober 2013 aangepast door Codx

[DoeEensGek]

Nee DoeEensGek, helaas...

 

Allereerst het zit wel degelijk bij de reader en niet bij de user. (zou ook niet eens kunnen)  En de dbv-api is een client die gebruik je niet bij servers alleen op de box zelf.. Sowieso veroorzaak die dvb-api een hoop ellende en raad ik het gebruik er van af.

 

Ten 2e ik heb net uitgelegd aan de hand van logs dat het hele cwcycle systeem niet werkt voor de anti-cs alleen op overgangen. En oscam stuurt ecm aanvragen richting alle readers  maar dat wil je niet want je verspeelt zo slots op al je kaarten. 

 

Tevens de cwcycle check kan helemaal niet triggeren dat er opnieuw wordt gevraagd. Dan doet de client zelf (in jou geval dvb-api)  maar dan nog is het geen gewenste situatie want je stuurt zo opnieuw een ecm naar de kaart(en) waardoor de kans groter wordt dat ze boven de limiet uitkomen. Kortom je graaft je eigen graf.

 

Het idee was leuk maar de cwcycle check hebben wij niks aan.  De reden waarom kaarten in anti-cs gaan ligt in de hoeveelheid ecm's of afwijkende ecm's en daar doet de cwcyclecheck niks mee want dat is achteraf. En het gevolg kan de cwcyclecheck niet uitfilteren, alleen op de overgang van beeld naar geen beeld of geen beeld naar beeld want dan is er een verschil meetbaar.

 

Duidelijker kan ik het niet maken voor je.

Codx... je zit er kilometers naast... echt kilometers...

 

De cycle chekc zit juist bij de users! Juist! Je kan de wiki en source code helemaal napluizen.

Vraag me direct af waarom je dvbapi niet zou gebruiken? Moet cccam blijven gebruiken dan?

Je kan prima oscam op de dreambox of welke enigma box dan ook, gebruiken. Zeker met pmtmode 6. Gaat zappen nog stukken sneller dan cccam.

Daarnaast heb je het over server en box... Oscam kan prima op de dreambox.

 

Dan kan je nog zelf instellen hoeveel ecm's en naar welke reader je de ecm's wil versturen.

 

Voordat je weer reageert, adviseer ik je toch echt eerst intelezen, oa in de oscam wiki. Hoe kom je erbij dat de cycle check bij de reader zit? Kijk voor de grap eens bij de webif bij users...

[Codx]

Ja tuurlijk joh..  . Je praat over dreamboxen met oscam en ik heb het over servers waarbij de insteek anders is. De cwcyclecheck kan niks voor je betekenen. Misschien moet je met de theparasol gaan praten, die kan het verhaal bevestigen.  Ik heb je net het bewijs middels logs gegeven, als je dat niet begrijpt kan ik er ook niks aan doen en houd de discussie verder op.

[DoeEensGek]

Ja tuurlijk joh..  . Je praat over dreamboxen met oscam en ik heb het over servers waarbij de insteek anders is. De cwcyclecheck kan niks voor je betekenen. Misschien moet je met de theparasol gaan praten, die kan het verhaal bevestigen.  Ik heb je net het bewijs middels logs gegeven, als je dat niet begrijpt kan ik er ook niks aan doen en houd de discussie verder op.

Dan houdt de discussie op... Ik snap dat je het moeilijk vind om te begrijpen... jammer.

[bennieboy]

Nou zie ik door de bomen het bos niet meer.. Omdat er 2 verschillende meningen over zijn.
En ik probeer ze allebij te begrijpen..
Denk dat ik het verhaal van codx een beetje begrijp.
Hoe zit het precies met de ecm's en cw's ? Als ik me box b.v. op sbs6hd zet dan gaat er een ecm request naar de kaart ?
En deze wordt beantwoord door een cw ? En cw staat voor control word heb ik begrepen ?
Heb ook iets begrepen dat een cw komplete hash is ? wat houdt hash in ?
En wat wordt bedoeld met fictionele cw's ? Ik dacht zover dat met om en om herhalend wordt bedoeld of de cw om de 10 sec zijn?
Maar begrijp dus uit het verhaal dat als een kaart in ant-cs gaat dit maar 1 keer wordt opgemerkt ?
Zit cwcycle check nou bij de user of bij de reader ?

Misschien dat een derde persoon hierover kan bevestigen welke theorie nou wel klopt en welke niet ??
En mij ook wat duidelijkheid kan geven over de ecm's en cw's
 

[theparasol]

ecm = entitlement control message, wordt naar kaart gestuurd en kaart geeft daar een controlword voor terug

emm = entitlement management message, wordt naar kaart gestuurd om keys of firmware te updaten.

 

Controlword cycle check = een relatief nieuw snufje van oscam die controleert of de kaart controlwords afgeeft die voldoen aan de controlword cycle. Vrijwel elke codering heeft deze repeating cycle. Een controlword bestaat uit twee gedeeltes cw0 en cw1, opeenvolgende controlwords hebben een repeating erin zitten. oude waarde cw1 komt bij volgende controlword in cw0 te staan en cw1 wordt vernieuwd.

Als controlword cyclecheck een afwijking bespeurd wordt deze gelogged en kan het controlword zelfs afgewezen worden, immers het voldoet niet aan de cyclecheck en daarmee zou deze dus ook geen beeld kunnen opleveren.

 

Anticascading is niets meer dan een truukje waarmee oscam het doorsharen door gebruikers kan detecteren en counteren.

Bv door vertraagd cw door te geven of fake cws. Dit als bv user duidelijk meer ecm requests doet dan bij normaal gebruik.

 

De anti-cs van de cds kaarten is heel wat anders. Die tellen domweg alle ecm-requests inclusief alle fake of invalid en kom je boven de taks dan worden *vermoedelijk* de masterkeys op de kaart zelf ge-encrypt waarmee dus elk controlword wat de kaart afgeeft onjuist is maar helaas wel voldoet aan de cw cyclecheck. Met franse nagra kaarten blijkt dat bepaalde premium kanalen minder ecm aanvragen tegelijk mogen krijgen. Dus icm premium filmkanaal mag je bv maar 1x ecm per controlwordcycle aanvragen, de standaard basis kanalen mag je bv wel 4x ecm per controlwordcycle aanvragen. Hierdoor is het allemaal extra ondoorzichtig hoe de kaart telt / reageert.

Het lijkt erop dat het met nederlandse kaarten ook gebeurt. Encrypted regionale kanalen mag je bv wel 6x ecm aanvragen, sommige andere kanalen maar 2x, de meesten wel 4x. Echter ik heb ook al eens gelezen dat tijdens belangrijke sportwedstrijden de kaart sneller locked dan als er geen belangrijke wedstrijd op is. Maar goed, zoals jullie weten heb ik zelf geen share netwerk of een full abbo kaart dus een en ander fatsoenlijk testen is er niet bij. 

7 oktober 2013 aangepast door theparasol

[Codx]

De regio zenders zou kunnen dat die 6 ecm aanvragen kunnen voordat de kaart gaat tellen maar dat komt dan omdat ecm-cycle nog op 15 seconde staan en rest op 10 sec. Vroeger was het altijd om de 15 sec trouwens maar sinds 2009 is dat veranderd.  De zenders die maar 2 ecm's kunnen hebben is het caid 1817 vs 0100 verhaal maar dat is jou ook bekend.

 

En dat locken als er een belangrijke wedstrijd wordt gespeeld dat speelt alleen bij sommige met een te levendige fantasie. Kijk in de oscam log en het is allemaal verklaarbaar.

 

Het punt blijft de cwcycheck kan ook DoeEensGek niet helpen in de strijd tegen de anti-cs al denkt die zelf van wel. Maar goed morgen is er weer een nieuwe uitdaging.

 

@bennyboy, met fictioneel bedoelde ik dat deze cw's niet echt zijn, anders zou ik ze liever niet publiceren

7 oktober 2013 aangepast door Codx

[bennieboy]

Ben wat traag van begrip.. Maar denk dat ik het wel begin te begrijpen.
Alhoewel ik het een paar keer goed moet doorlezen  
Begrijp nu dus met het verhaal van theparasol. Dat een ecm verzoek naar de kaart wordt gestuurd en deze geeft hierop een controlword terug ? Wat bevat een controlword ? Zit hier een key in ?
En wordt met cycle nou bedoeld een bepaalde tijd ? Dat je kaart om de zoveel tijd cw's blijft afgeven ?
Is dit trouwens het eenigste wat je kaart doet enkeld cw's afgeven ?

 

Als er een ecm verzoek wordt gedaan aan de kaart. krijgt deze dus (1) controlword maar hij bestaat uit 2 gedeeltes ?

Je hebt het er ook over dat je de basis kanalen 4x ecm per controlwordcycle mag aanvragen...
Begrijp nou ik hieruit dat je met cdnl binnen de 10 sec 4 ecm mag aanvragen ?

 

Hoe zit het trouwens met caid 1817 en 1818 ?
Zodra ik me box op een zender zet krijg ik dus dit te zien op de web interface.

2013/10/08 10:42:13 599F08 c dvbapi: [ADD PID 0] CAID: 1817    ECM_PID: 0717    PROVID: 00006A
2013/10/08 10:42:13 599F08 c dvbapi: [ADD PID 1] CAID: 0100    ECM_PID: 0717    PROVID: 00006A

Wat is caid 1817 ?

Bedankt weer.