4250 replies to this topic

[Erik Slagter]

gebruikt zouden worden. Maar op deze manier werkt dat dus niet. Je weet nooit of een cw die je krijgt goed is. Tenzij iemand een keer het algoritme kraakt waarmee de fake codewords gemaakt worden, zo iemand zal erg populair worden

Um, ja, ok, maar wacht eens even... Enigma weet natuurlijk *wel* wanneer het codeword niet klopt (zwarte output). Dus vanuit enigma zou dat moeten kunnen worden gelogd?

Nee helaas zo werkt het niet. Enigma heeft hier niks mee te maken. De softcam trekt zelf continu de ecm's uit de demuxer (ecm pid), doet daar "iets" mee om er een codeword van te maken (aanbieden aan kaart of server) en dat codeword, dat prakt de softcam zelf in de descrambler. Het enige punt waar enigma wat mee doet, is als er gezapt wordt, dan laat enigma via een capmt aan de softcam weten welke chids er actief zijn.

Noch enigma, noch de softcam kan weten of een codeword correct is. Het enige wat je zou kunnen doen is de gedecrypte stream gaan ontleden om te kijken of dat er "geldig" uit ziet, dat is niet haalbaar. De videodecoder heeft misschien ergens een bitje in een register die aangeeft of er geldige data wordt ontvangen, maar dan nog zou je elke keer bij een fout codeword even een zwart scherm hebben....

Edited by Erik Slagter, 24 September 2012 - 12:17.

[BuGless]

Heeft al iemand het uitgeprobeerd? Ik heb er een hard hoofd in, mijn ervaring is dat wat je ook doet, als je meer dan vier chids afneemt, dan gaat-ie vroeger of later in penalty, ook met zappen. Ook al zegt Nagra/CDS dat dat niet zo is.

Ik zou normaliter verwachten dat ze een hele simpele token-bucket-limiter hebben gemaakt. I.e. je definieert een tijdspanne (bijv. 10 minuten), je definieert een aantal requests dat maximaal in die tijd mag plaatsvinden (bijv. 240), en je neemt voor elke request 1 token uit je bucket, en elke 2.5 seconden doe je weer een token in je bucket; bij meer dan 240 tokens, gooi je tokens weg; bij 0 tokens geef je fake CWs terug.
En als ze dat gedaan hebben, dan is er verder geen speciale burst handling nodig (en volgens het KISS principe zou dit dan ook moeten lijken op de oplossing die ze gebruiken).

Ze kunnen het zich vermoedelijk niet permitteren om elke 10 seconden de flash bij te werken om op te slaan hoeveel in de bucket zit, dus dan zit de bucket wellicht enkel in RAM, hetgeen betekent dat op het moment dat je de kaart stroom geeft (boot), hij vermoedelijk begint met 0 tokens in de bucket, en pas na 2.5 seconden de eerste token vult.

Penalty mode is dan te implementeren met een check in RAM of je binnen een tijdsbestek van een paar minuten met enige regelmaat 0 tokens hebt en toch een query probeert te doen. Indien je dat constateert als kaart, zet je in de flash een penalty flag, die pas na een bepaalde cooldown periode weer gewist wordt.

[BuGless]

Het enige wat je zou kunnen doen is de gedecrypte stream gaan ontleden om te kijken of dat er "geldig" uit ziet, dat is niet haalbaar.

Dus in de videostream zit geen structuur meer met bepaalde magics op vaste posities die je vlug zou kunnen controleren?
Dus als je een kanaal aanbiedt aan je video decoder zonder de correcte sleutel, is er een bepaalde kans dat je de videodecoder laat vastlopen omdat hij vanwege een of andere obscure (buffer overflow) bug hangt?

[Erik Slagter]

Ik zou normaliter verwachten dat ze een hele simpele token-bucket-limiter hebben gemaakt. I.e. je definieert een tijdspanne (bijv. 10 minuten), je definieert een aantal requests dat maximaal in die tijd mag plaatsvinden (bijv. 240), en je neemt voor elke request 1 token uit je bucket, en elke 2.5 seconden doe je weer een token in je bucket; bij meer dan 240 tokens, gooi je tokens weg; bij 0 tokens geef je fake CWs terug.
En als ze dat gedaan hebben, dan is er verder geen speciale burst handling nodig (en volgens het KISS principe zou dit dan ook moeten lijken op de oplossing die ze gebruiken).
...

Dat zou wel een heel eenvoudige methode zijn Het probleem hiermee is dat zappen onmogelijk wordt. Er zit dus stiekem nog iets van een burst mode in. Voor zover ik kan zien lijkt het er op dat ze die burst mode met opzet wat onvoorspelbaar hebben gemaakt. Ook het opbouwen en afbouwen van penalty mode (hij is niet "aan" of "uit", maar loopt op en af) lijkt een random onderdeel te hebben. Die jongens van Nagra zijn niet helemaal gek natuurlijk. Dat verklaart dan ook misschien waarom die kaarten zo duur zijn

[Erik Slagter]

Het enige wat je zou kunnen doen is de gedecrypte stream gaan ontleden om te kijken of dat er "geldig" uit ziet, dat is niet haalbaar.

Dus in de videostream zit geen structuur meer met bepaalde magics op vaste posities die je vlug zou kunnen controleren?
Dus als je een kanaal aanbiedt aan je video decoder zonder de correcte sleutel, is er een bepaalde kans dat je de videodecoder laat vastlopen omdat hij vanwege een of andere obscure (buffer overflow) bug hangt?

Er zit wel wat structuur in een mpeg2 es en een h264 es die aan de decoder worden aangeboden, maar niet heel veel, dat zou de compressie immers tenietdoen. De meeste redundantie is er wel uit met het uitpakken uit de transport stream. Misschien zou er iets mogelijk zijn met controle op de timestamps, die moeten meestal (!) netjes monotoon oplopen binnen bepaalde grenzen. Hoe dan ook, die hele videostream loopt "binnendoor" van de demuxer naar de videodecoder, daar zit enigma absoluut niet tussen. Als je enigma hard (!) killt, dan blijft je programma gewoon doorlopen, probeer maar eens...

En ja, de videodecoder (en ook de demuxer) van een STB moet bijzonder robuust zijn omdat hij zelfs met input van /dev/random niet mag vastlopen. Ook dat STB'en een beetje picky zijn in wat ze afspelen zal daar vast wel mee te maken hebben.

[Erik Slagter]

Ze kunnen het zich vermoedelijk niet permitteren om elke 10 seconden de flash bij te werken om op te slaan hoeveel in de bucket zit, dus dan zit de bucket wellicht enkel in RAM, hetgeen betekent dat op het moment dat je de kaart stroom geeft (boot), hij vermoedelijk begint met 0 tokens in de bucket, en pas na 2.5 seconden de eerste token vult.

Dat is zo'n beetje het eerste wat door de hobbyisten getest is en nee, dat werkt dus niet zo. Je kunt "penalty tokens" alleen kwijtraken door het aanbieden van aardig wat geldige (!) ECM's en dan ook in een geldig tempo. Kaart van de spanning afhalen of resetten helpt niet.

Hoe ze dat precies gedaan hebben weet ik niet, maar je zou kunnen denken aan een klein stukje speciale flash wat ontzettend vaak beschreven kan worden, of mram enz. Daar is wel wat op te bedenken. Nogmaal ze zijn niet gek bij Nagra. Moet ook wel, als je bedenkt wat een booming business card sharing is (met name commercieel dus).

[BuGless]

Ik zou normaliter verwachten dat ze een hele simpele token-bucket-limiter hebben gemaakt.

Dat zou wel een heel eenvoudige methode zijn Het probleem hiermee is dat zappen onmogelijk wordt.

Dat hangt sterk van de maximale vulwaarde van de bucket af. Stel dat die waarde van max. 240 tokens in een bucket klopt, dan betekent dat nadat ik een tijdje 1 kanaal gekeken heb, en 1 kanaal opneem, de bucket vol is (ik neem elke 10 seconden 2 tokens eruit, en vul 4 bij). Dus als ik dan ga zappen kan ik 240 kanalen zappen voordat er iets foutgaat. Doorgaans heb je binnen 240 kanalen wel iets gevonden (ik zap geen 240 kanalen, zit duidelijk boven dat wat je typischerwijs doorzapt (zou ik zeggen)).

Dus dan zou ik normaliter zeggen, er is geen speciale burst handling nodig, om de use case af te dekken van een kijker die 1 kanaal kijkt, 1 kanaal opneemt, en dan soms een beetje rondzapt.

Edited by BuGless, 24 September 2012 - 13:23.

[Hotzenwalder]

Hoe kan ik voor ZIGGO de ecmheader vinden die gebruikt kan worden voor de whitelist.

Bijvoorbeeld

2012/09/24 14:21:03 1433910 c Client l_5555_frontend01 ECM dump 0604&000000/01F4/00C5/44:2A68
2012/09/24 14:21:03 1433910 80 70 41 51 00 00 01 F4 00 08 40 38 95 BD 6E 5E
2012/09/24 14:21:03 1433910 E8 4C DB 81 33 68 93 96 2F E0 21 57 AD 78 62 AA
2012/09/24 14:21:03 1433910 EA 39 E9 01 DA 34 0B C9 1B A4 C9 47 D5 A7 D9 54
2012/09/24 14:21:03 1433910 ED 33 44 F8 EB 12 3C D2 41 E0 36 47 70 16 3D D8
2012/09/24 14:21:03 1433910 99 59 4E 1A
2012/09/24 14:21:03 FC0008B0 r data from add_job action=5 client r localbc
2012/09/24 14:21:03 FC0008B0 r ecm:
2012/09/24 14:21:03 FC0008B0 80 70 41 51 00 00 01 F4 00 08 40 38 95 BD 6E 5E
2012/09/24 14:21:03 FC0008B0 E8 4C DB 81 33 68 93 96 2F E0 21 57 AD 78 62 AA
2012/09/24 14:21:03 FC0008B0 EA 39 E9 01 DA 34 0B C9 1B A4 C9 47 D5 A7 D9 54
2012/09/24 14:21:03 FC0008B0 ED 33 44 F8 EB 12 3C D2 41 E0 36 47 70 16 3D D8
2012/09/24 14:21:03 FC0008B0 99 59 4E 1A
2012/09/24 14:21:03 FC0008B0 r localbc [irdeto] write to cardreader
2012/09/24 14:21:03 FC0008B0 05 00 00 02 3E 01 F4 00 08 40 38 95 BD 6E 5E E8
2012/09/24 14:21:03 FC0008B0 4C DB 81 33 68 93 96 2F E0 21 57 AD 78 62 AA EA
2012/09/24 14:21:03 FC0008B0 39 E9 01 DA 34 0B C9 1B A4 C9 47 D5 A7 D9 54 ED
2012/09/24 14:21:03 FC0008B0 33 44 F8 EB 12 3C D2 41 E0 36 47 70 16 3D D8 99
2012/09/24 14:21:03 FC0008B0 59 4E 1A
2012/09/24 14:21:03 FC0008B0 r localbc [irdeto] IFD: Transmit:
2012/09/24 14:21:03 FC0008B0 01 05 00 00 02 3E 01 F4 00 08 40 38 95 BD 6E 5E
2012/09/24 14:21:03 FC0008B0 E8 4C DB 81 33 68 93 96 2F E0 21 57 AD 78 62 AA
2012/09/24 14:21:03 FC0008B0 EA 39 E9 01 DA 34 0B C9 1B A4 C9 47 D5 A7 D9 54
2012/09/24 14:21:03 FC0008B0 ED 33 44 F8 EB 12 3C D2 41 E0 36 47 70 16 3D D8
2012/09/24 14:21:03 FC0008B0 99 59 4E 1A F5
2012/09/24 14:21:03 FC0008B0 r localbc [irdeto] IO: SR: Transmit:
2012/09/24 14:21:03 FC0008B0 01 05 00 00 02 3E 01 F4 00 08 40 38 95 BD 6E 5E
2012/09/24 14:21:03 FC0008B0 E8 4C DB 81 33 68 93 96 2F E0 21 57 AD 78 62 AA
2012/09/24 14:21:03 FC0008B0 EA 39 E9 01 DA 34 0B C9 1B A4 C9 47 D5 A7 D9 54
2012/09/24 14:21:03 FC0008B0 ED 33 44 F8 EB 12 3C D2 41 E0 36 47 70 16 3D D8
2012/09/24 14:21:03 FC0008B0 99 59 4E 1A F5

[BuGless]

Ze kunnen het zich vermoedelijk niet permitteren om elke 10 seconden de flash bij te werken om op te slaan hoeveel in de bucket zit, dus dan zit de bucket wellicht enkel in RAM, hetgeen betekent dat op het moment dat je de kaart stroom geeft (boot), hij vermoedelijk begint met 0 tokens in de bucket, en pas na 2.5 seconden de eerste token vult.

Dat is zo'n beetje het eerste wat door de hobbyisten getest is en nee, dat werkt dus niet zo. Je kunt "penalty tokens" alleen kwijtraken door het aanbieden van aardig wat geldige (!) ECM's en dan ook in een geldig tempo. Kaart van de spanning afhalen of resetten helpt niet.

Dat is niet wat ik zeg. Vermoedelijk loopt de normale bucket in RAM, enkel het penalty management wordt geflashed. Als je het op die manier doet, hoef je alleen in geval van penalty mode de flash aan te spreken, dat zou zelden moeten zijn.

[Hotzenwalder]

Afgaande op andere sites zouden de eerste 20 tekens uit de header de juiste header moeten zijn. Ik herken in de header wel een CHID, dus ik vermoed dat er dan net zoveel geldige headers zijn als CHIDS van ZIGGO (chids = pakketten). Als iemand me kan vertellen tot hoeveel tekens ik moet gaan dan kan ik zelf wel de juiste headers eruit vissen denk ik na een avondje zappen

[Erik Slagter]

Dat hangt sterk van de maximale vulwaarde van de bucket af. Stel dat die waarde van max. 240 tokens in een bucket klopt, dan betekent dat nadat ik een tijdje 1 kanaal gekeken heb, en 1 kanaal opneem, de bucket vol is (ik neem elke 10 seconden 2 tokens eruit, en vul 4 bij). Dus als ik dan ga zappen kan ik 240 kanalen zappen voordat er iets foutgaat. Doorgaans heb je binnen 240 kanalen wel iets gevonden (ik zap geen 240 kanalen, zit duidelijk boven dat wat je typischerwijs doorzapt (zou ik zeggen)).

Dus dan zou ik normaliter zeggen, er is geen speciale burst handling nodig, om de use case af te dekken van een kijker die 1 kanaal kijkt, 1 kanaal opneemt, en dan soms een beetje rondzapt.

Klinkt als tbf (rate limiter/policer in de linux kernel) En dan klopt het inderdaad.

Edited by Erik Slagter, 24 September 2012 - 14:56.

[Erik Slagter]

Dat is niet wat ik zeg. Vermoedelijk loopt de normale bucket in RAM, enkel het penalty management wordt geflashed. Als je het op die manier doet, hoef je alleen in geval van penalty mode de flash aan te spreken, dat zou zelden moeten zijn.

En als je vrijwel continu in/out penalty mode gaat, dan rook je vanzelf je flash op, wat CDS helemaal niet zo erg zal vinden

Maar even terug, het is dus praktisch onmogelijk om te detecteren of, en in hoeverre, de kaart in penalty mode staat, helaas. En als je er over nadenkt is dat ook wel logisch dus.

[Erik Slagter]

Dit is misschien ook nog interessant (en misschien ook niet )

Ik heb al vanaf het begin van dat ik oscam gebruik, en dat is al een aardig tijdje geleden, het probleem dat als je server even een tijdje niet reageert (om wat voor reden dan ook), dat de client stopt met cw's opvragen, waardoor je niet een stukje van je opname kwijt bent, maar gewoon alles vanaf dat punt. Hier hadden verstokte CCcam-gebruikers een sterk punt.

Het is me nu gelukt om dat werkend te krijgen. Ik heb daarvoor de laatste oscam gebruikt (versie van vandaag), ik weet niet of dat verplicht is. Verder heb ik voor de caid's (100:6a in dit geval) een p: regel opgenomen met een "1" parameter erachter. Wat ik ook heb gedaan, is bij het door mij gebruikte camd35 protocol de suppresscmd08 uitzetten (dat moet zowel bij client als server), want die zorgt er (ook) voor dat de client caid's niet eindeloos blijven opvragen. Op zich is dat wel een goede taktiek, maar soms wil je dat niet...

En dán werkt het dus netjes. Ik heb de oscam op de server verschillende keren compleet gestopt en pas na wat langere tijd weer aangezet en het beeld komt dan netjes weer terug.

[deleted]

Dit is misschien ook nog interessant (en misschien ook niet )

Ik heb al vanaf het begin van dat ik oscam gebruik, en dat is al een aardig tijdje geleden, het probleem dat als je server even een tijdje niet reageert (om wat voor reden dan ook), dat de client stopt met cw's opvragen, waardoor je niet een stukje van je opname kwijt bent, maar gewoon alles vanaf dat punt. Hier hadden verstokte CCcam-gebruikers een sterk punt.

Het is me nu gelukt om dat werkend te krijgen. Ik heb daarvoor de laatste oscam gebruikt (versie van vandaag), ik weet niet of dat verplicht is. Verder heb ik voor de caid's (100:6a in dit geval) een p: regel opgenomen met een "1" parameter erachter. Wat ik ook heb gedaan, is bij het door mij gebruikte camd35 protocol de suppresscmd08 uitzetten (dat moet zowel bij client als server), want die zorgt er (ook) voor dat de client caid's niet eindeloos blijven opvragen. Op zich is dat wel een goede taktiek, maar soms wil je dat niet...

En dán werkt het dus netjes. Ik heb de oscam op de server verschillende keren compleet gestopt en pas na wat langere tijd weer aangezet en het beeld komt dan netjes weer terug.

Dit heb ik enkele posts terug al eens gemeld voor iemand http://openpli.org/f...post__p__294043

Heb jij het ook in DVBAPI staan of in oscam.whitelist?

[bambike]

Dit is misschien ook nog interessant (en misschien ook niet )

Ik heb al vanaf het begin van dat ik oscam gebruik, en dat is al een aardig tijdje geleden, het probleem dat als je server even een tijdje niet reageert (om wat voor reden dan ook), dat de client stopt met cw's opvragen, waardoor je niet een stukje van je opname kwijt bent, maar gewoon alles vanaf dat punt. Hier hadden verstokte CCcam-gebruikers een sterk punt.

Het is me nu gelukt om dat werkend te krijgen. Ik heb daarvoor de laatste oscam gebruikt (versie van vandaag), ik weet niet of dat verplicht is. Verder heb ik voor de caid's (100:6a in dit geval) een p: regel opgenomen met een "1" parameter erachter. Wat ik ook heb gedaan, is bij het door mij gebruikte camd35 protocol de suppresscmd08 uitzetten (dat moet zowel bij client als server), want die zorgt er (ook) voor dat de client caid's niet eindeloos blijven opvragen. Op zich is dat wel een goede taktiek, maar soms wil je dat niet...

En dán werkt het dus netjes. Ik heb de oscam op de server verschillende keren compleet gestopt en pas na wat langere tijd weer aangezet en het beeld komt dan netjes weer terug.

Dat van die opname was mij ook al opgevallen en daardoor bleef ik voor cccam kiezen
Heb je voorbeeldje ??
Lezen en lezen en lezen maar na een tijdje zie je hier het bos niet meer door de bomen

[BuGless]

Dat hangt sterk van de maximale vulwaarde van de bucket af. Stel dat die waarde van max. 240 tokens in een bucket klopt

Klinkt als tbf (rate limiter/policer in de linux kernel) En dan klopt het inderdaad.

Dan hebben we nu nog een vrijwilliger nodig die z'n kaart eerst een half uurtje laat bijtanken (max. 1 zender opvragen), en dan de kaart in zo kort mogelijke tijd bombardeert met requests (bijv. voorkeur zelfs nog requests met de verkeerde caid, want die worden (als het goed is) gelijk door de kaart geweigerd), en dan een zo nauwkeurig mogelijke timing tussen het moment van starten van het bombardement, hoeveel extra ECMs je ernaar toe stuurt, en het tijdstip waarop het beeld de eerste keer zwart wordt. Daarna kun je uitrekenen wat de maximale vulwaarde van de bucket is (mits ze dit (simpelste) algorithme gebruiken).

[deleted]

Ik heb in oscam.dvbapi het volgende staan:

P: 0100:00006C 1 # TV Vlaanderen

Dit staat er al maanden in, dus heb je niet de laatste versie voor nodig, je kunt ook gewoon cccam als protocol blijven gebruiken.

Of dat hij het ook doet in oscam.whitelist dat heb ik zelf nog niet getest.

Die 1 zorgt er gewoon voor dat hij blijft proberen, is toch al heel lang bekent dacht ik.
Wil je een kaart updaten die vervallen is, bv van de camping, dan moet je dit ook gebruiken.
CCcam hoeft niemand nog te gebruiken, als men de moeite neemt om Oscam te leren.

[Erik Slagter]

Dit heb ik enkele posts terug al eens gemeld voor iemand http://openpli.org/f...post__p__294043
Heb jij het ook in DVBAPI staan of in oscam.whitelist?

Ik heb het zelf al een tijdje (ik denk wel een half jaar) niet meer geprobeerd, omdat ik daarvoor er héél veel tijd in had gestoken en het nooit goed kreeg. Dus het zou best kunnen dat het al een tijdje wel goed werkt inmiddels.

Daar komt nog bij dat ik oscam ook als client gebruik en dat ik, zoals aangeraden wordt, het camd35 protocol gebruik tussen oscam-oscam, dat maakt het toch net iets anders. Je moet dan dus ook die suppresscmd08 aanzetten. Ik heb gemerkt dat het camd35 protocol veel zuiniger met geheugen is, omdat hij niet zoals cccam probeert alle caid:srvid's van de server te downloaden, maar gewoon caids:srvid's probeert wanneer ze langskomen (en het resultaat daarvan dan eventueel cache'd).

Dit is een instelling de dvbapi. In de whitelist kun je nou eenmaal niet forceren dat een caid eindeloos geprobeerd moet worden, dat is juist de hele crux.

[Erik Slagter]

Dat van die opname was mij ook al opgevallen en daardoor bleef ik voor cccam kiezen
Heb je voorbeeldje ??
Lezen en lezen en lezen maar na een tijdje zie je hier het bos niet meer door de bomen

Wat is precies niet duidelijk uit wat ik uitgelegd had? p: regel? suppresscmd08?

[Erik Slagter]

Dan hebben we nu nog een vrijwilliger nodig die z'n kaart eerst een half uurtje laat bijtanken (max. 1 zender opvragen), en dan de kaart in zo kort mogelijke tijd bombardeert met requests (bijv. voorkeur zelfs nog requests met de verkeerde caid, want die worden (als het goed is) gelijk door de kaart geweigerd), en dan een zo nauwkeurig mogelijke timing tussen het moment van starten van het bombardement, hoeveel extra ECMs je ernaar toe stuurt, en het tijdstip waarop het beeld de eerste keer zwart wordt. Daarna kun je uitrekenen wat de maximale vulwaarde van de bucket is (mits ze dit (simpelste) algorithme gebruiken).

Hoor ik daar een vrijwilliger ?

Verkeerde caid requests tellen volgens mij niet mee voor de penalty. Verkeerde sid's misschien wel.