Angenommen es sind Fakes (morgen weiss ich mehr), was spräche denn gegen eine Option die CWs ab x ms zu verwerfen?
Digital Eliteboard - Das Digitale Technik Forum
Registriere dich noch heute kostenloses um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereiche, welche für Gäste verwehrt bleiben
- Registriert
- 10. Dezember 2012
- Beiträge
- 11.645
- Lösungen
- 2
- Reaktionspunkte
- 25.470
- Punkte
- 1.103
Es gibt hier im gesamten Thread überhaupt keinen Beweis für Fake cws. Alles nur Behauptungen.
Frage mich, warum hier überhaupt gefragt wird, wenn man keine konkreten Informationen liefern will.
Frage mich, warum hier überhaupt gefragt wird, wenn man keine konkreten Informationen liefern will.
- Registriert
- 30. Dezember 2009
- Beiträge
- 18.120
- Lösungen
- 11
- Reaktionspunkte
- 21.643
- Punkte
- 1.103
Weil es nichts bringt, wie ich auf Seite 1 schon Erläutert habe.
Aber gerne nochmal: Anfrage kommt Verzögert beim Server an (High Ping etc) > Server hat CW schon berechnet (anderer Client) > Server schickt CW aus Cache (Schnelle Berechnung) > CW kommt zu schnell beim Client an und wird mit der Option CWs zu droppen unter X ms verworfen = Standbild (obwohl das CW gültig war)
Und nun? Was hast du jetzt gewonnen?
Edit: Je mehr Hops drin stecken in der ganzen Kette desto häufiger kann so ein eine Verspätete Abfrage passieren.
Ja ja ,das ist klar, aber die Option würde nützen wenn sich die Annahme bestätigt, dass es Fakes sind.
Ich versuche jetzt einmal mittels delayer zu testen da ich sonst keinen Möglichkeit habe festzustellen ob es Fakes sind.
@pehedima ... zu deinem Post. Wenn ich wüsste dass es Fakes sind stände es schon im OP. Daher kein Beweis. Sorry.
Ich versuche jetzt einmal mittels delayer zu testen da ich sonst keinen Möglichkeit habe festzustellen ob es Fakes sind.
@pehedima ... zu deinem Post. Wenn ich wüsste dass es Fakes sind stände es schon im OP. Daher kein Beweis. Sorry.
Zuletzt bearbeitet:
DVB-T2 HD
DEB König
- Registriert
- 13. April 2016
- Beiträge
- 6.131
- Lösungen
- 4
- Reaktionspunkte
- 6.734
- Punkte
- 393
Wenn es wirklich an Fake-CWs liegen sollte, dann sollte man sich mal mit dem CW-Server befassen, der die ausliefert. Oder kann man die Fake-CWs dort auch nicht unterdrücken, sprich verwerfen? Würde ja bedeuten, dass alle CardSharing-Nutzer das Problem haben müssten, denke ich.
- Registriert
- 30. Dezember 2009
- Beiträge
- 18.120
- Lösungen
- 11
- Reaktionspunkte
- 21.643
- Punkte
- 1.103
Der dann auch zu Schnell liefert weil schon wieder Zeit vergangen ist während der Check Prozess lief.
w33dburner
Ist gelegentlich hier
- Registriert
- 16. April 2009
- Beiträge
- 85
- Reaktionspunkte
- 326
- Punkte
- 73
das wäre schön, wenn man gültige CWs erkennen könnte ;>
Ach so ... wie denn?
el_malto
Elite User
- Registriert
- 15. September 2017
- Beiträge
- 1.786
- Lösungen
- 2
- Reaktionspunkte
- 2.280
- Punkte
- 393
Man kann 100% "gültige" CWs eigentlich nur mit dem Patch von @w33dburner -der jetzt auch im trunk ist- und den "lokal generatet" Parametern erkennen. Alle anderen "könnten" fake sein. Leider wird der Patch nicht von allen verwendet bzw. benutzen die Paylines diesen nicht.
Wenn man also keinen "vertrauenswürdigen" Sharepartner hat, gibt es keine 100% Lösung fake CWs zu erkennen.
So ist es. Aber dann stellt sich auch die Frage was man dann mit einen Proxy/CEX will wenn man einen 100% zulässigen Reader hat?
Die Idee mit den fallbacks finde ich aber interessant. Das Problem ist nur, wenn man (wir wissen alle um welche Karte es zu diesen Thema ja immer geht) keine V13 hat und diese nur über einen CEX (der ja meistens) Pay ist rein bekommt, nützt ein fallback zu einen anderen CEX auch nicht wirklich was. Ich habe mir mal die Mühe gemacht und lange Zeit mehrere Pays getestet. Das ergebnis war, dass zu 95% alle Pays von den gleichen CEX gespeist werden. Haben es mit mehreren Receivern und Paylines zur gleichen Zeit getestet. Wenn es zu 7 Sek. Freezern gekommen ist, stand das Bild bei allen.
100% sicherheit bringt nur wenn die komplette Kette den lg Patch nutzen.
Zum Betreff dieses Threads - die schnellen CWs sind nicht immer die Fakes. Diese zu ermitteln ist in der Tat sehr viel schwieriger als ich dachte, sogar mit CE/AIO.
Ich habe mich jetzt 2 Wochen mit CE auseinandergesetzt. Den totalen Durchblick habe ich allerdings noch lange nicht. Die Mechanismen von CE (und AIO Patch) sind toll, aber ich möchte wissen ob ich sie auch für meinen Zweck einsetzen kann. Ein User hier im Forum (der coded/patched und es sicher weiss) hat mir per PM gesagt es sei nicht möglich. Ich habe aber inzwischen einige Ansätze geändert und möchte gerne wissen ob ich nichts Wesentliches übersehen habe.
Ich habe 3 Proxys. Einer hat eine Karte, aber ich hatte auch schon Fakes von diesem Reader. Testweise habe ich mir noch 2 Paylines besorgt (inklusive Fakes). Meine Idee war jetzt, die 3 Proxys von der User-Instanz in die CE-Instanz zu pushen, damit wait_time = 0:300 / cacheex_cw_check = 0:0:2 die Fakes rausschmeißt (ober zumindest reduziert). Klar, das entspricht nicht der Idee des CE, aber ich share auch nicht. Ziel ist nur die Fakes lokal loszuwerden. User- und CE-Instanz haben CE2 user/reader in beide Richtungen.
Erste Idee war, die Gruppen so aufzuteilen, dass ich die ECMs gleichzeitig an die 3 Proxies und den CE schicke. Die CWs werden dann von der User-Instanz in die CE-Instanz gepushed, und mittels wait_time / cacheex_cw_check bearbeitet (ja, ist nicht 100%ig, aber besser als den schnellsten Proxy zu nehmen). Das Dumme ich nur, daß die Box die den ECM schickt, die schnellste Antwort nimmt, was natürlich einer der 3 Proxies ist und nicht der CE mit dem "geprüften" CW. Da OSCam nicht vorsieht ECM Anfragen an x Reader zu schicken, aber nur eine Antwort (CW) anzunehmen, läuft dieser Ansatz ins Leere. Man könnte jetzt zweite Box_2 auf den gleichen Sender zu setzen, die dann nur CWs vom CE bekäme. Das klappt, ist aber alles andere als "elegant".
Eine andere Idee war, dass die Box den ECM nur (!) an die CE-Instanz schickt, die den ECM gleich (ohne wait_time abzuwarten) an die User-Instanz zwecks Proxy Abfrage zurückschickt.
ECM -> CE-I -> U-O -> Proxy
CW -> U-I -> CE-I (Überprüfung) -> U-I
Das geht AFAIK auch nicht da immer wait_time abgewartet wird bevor ein ECM weitergeleitet wird.
Was habe ich übersehen?
Ich habe mich jetzt 2 Wochen mit CE auseinandergesetzt. Den totalen Durchblick habe ich allerdings noch lange nicht. Die Mechanismen von CE (und AIO Patch) sind toll, aber ich möchte wissen ob ich sie auch für meinen Zweck einsetzen kann. Ein User hier im Forum (der coded/patched und es sicher weiss) hat mir per PM gesagt es sei nicht möglich. Ich habe aber inzwischen einige Ansätze geändert und möchte gerne wissen ob ich nichts Wesentliches übersehen habe.
Ich habe 3 Proxys. Einer hat eine Karte, aber ich hatte auch schon Fakes von diesem Reader. Testweise habe ich mir noch 2 Paylines besorgt (inklusive Fakes). Meine Idee war jetzt, die 3 Proxys von der User-Instanz in die CE-Instanz zu pushen, damit wait_time = 0:300 / cacheex_cw_check = 0:0:2 die Fakes rausschmeißt (ober zumindest reduziert). Klar, das entspricht nicht der Idee des CE, aber ich share auch nicht. Ziel ist nur die Fakes lokal loszuwerden. User- und CE-Instanz haben CE2 user/reader in beide Richtungen.
Erste Idee war, die Gruppen so aufzuteilen, dass ich die ECMs gleichzeitig an die 3 Proxies und den CE schicke. Die CWs werden dann von der User-Instanz in die CE-Instanz gepushed, und mittels wait_time / cacheex_cw_check bearbeitet (ja, ist nicht 100%ig, aber besser als den schnellsten Proxy zu nehmen). Das Dumme ich nur, daß die Box die den ECM schickt, die schnellste Antwort nimmt, was natürlich einer der 3 Proxies ist und nicht der CE mit dem "geprüften" CW. Da OSCam nicht vorsieht ECM Anfragen an x Reader zu schicken, aber nur eine Antwort (CW) anzunehmen, läuft dieser Ansatz ins Leere. Man könnte jetzt zweite Box_2 auf den gleichen Sender zu setzen, die dann nur CWs vom CE bekäme. Das klappt, ist aber alles andere als "elegant".
Eine andere Idee war, dass die Box den ECM nur (!) an die CE-Instanz schickt, die den ECM gleich (ohne wait_time abzuwarten) an die User-Instanz zwecks Proxy Abfrage zurückschickt.
ECM -> CE-I -> U-O -> Proxy
CW -> U-I -> CE-I (Überprüfung) -> U-I
Das geht AFAIK auch nicht da immer wait_time abgewartet wird bevor ein ECM weitergeleitet wird.
Was habe ich übersehen?
Zuletzt bearbeitet:
