Aktuelles
Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenlos, 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 Bereichen, welche für Gäste verwehrt bleiben

Registriere dich noch heute kostenlos, 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 Bereichen, welche für Gäste verwehrt bleiben

SoftCSA OpenATV

Wie es funktioniert:
1. CSA (Common Scrambling Algorithm) - der DVB-Standard-Verschlüsselungsalgorithmus seit den 90ern. Öffentlich dokumentiert und in libdvbcsa oder auch ffdecsa implementiert.
2. CSA-ALT (Algorithm 3) - eine Variante von CSA mit einer anderen Permutationstabelle. Immer noch CSA, nur mit leicht modifizierter Mathematik.
3. Das CW (Control Word) - der 8-Byte Schlüssel der alle ~7 Sekunden wechselt. Das CW kommt von der Smartcard nicht von SoftCSA.

Was SoftCSA macht:
SoftCSA führt nur den Descrambling-Algorithmus in Software aus statt in Hardware. Es berechnet nichts Geheimes - es wendet nur das bekannte CSA-ALT Verfahren mit dem empfangenen CW auf den Stream an.

Die Permutationstabelle:
Die Tabelle ist in libdvbcsa vorhanden. Bei CSA-ALT wird das CW nicht direkt verwendet, sondern erst durch die Permutationstabelle “geschickt”. Das ist eine Art Lookup-Tabelle die Bytes umsortiert/transformiert. Wenn du das falsche Mapping verwendest, kommt beim Descrambling Müll raus - obwohl das CW korrekt ist. Der Algorithmus ist identisch zu Standard CSA, nur die Tabelle ist anders. Hardware-Descrambler in normalen Receivern haben die Standard-Tabelle fest eingebaut und können CSA-ALT nicht entschlüsseln.

Was sich ändern könnte:
∙ Wenn sich die Permutationstabelle ändert → libdvbcsa Update nötig
∙ Wenn sich der ECM-Mode ändert → libdvbcsa Update nötig
∙ CW-Updates → egal, kommt von der Smartcard, SoftCSA ist nicht betroffen

Kurz: SoftCSA ist nur ein “Rechenknecht” - die eigentliche Sicherheit liegt im CW, das weiterhin von der Smartcard kommt.
 
Zuletzt bearbeitet:
Warum hat man ICAM eigentlich nicht CSA-ALT (Algorithm 3) oder CSA3 genannt?
Als Sky auf ICAM umgestellt hat hieß es immer, dass Sky sich nicht an den DVB Standard hält. Aber CSA3 ist doch ein Standard oder nicht?
Ist doch alles das gleiche oder?
Wenn wir schon einmal beim "wording" sind.
 
Zuletzt bearbeitet:
ICAM ist der offizielle Begriff von VideoGuard für die Conditional-Access-Lösung die CSA-ALT verwendet. Broadcom hat 2011 STB-Chips mit dem NDS VideoGuard Security Kernel integriert, die ICAM-Features enthalten.
Also:
∙ ICAM = der offizielle Marketing-/Produktname
∙ CSA-ALT / Algorithm 3 = die technische Bezeichnung für den modifizierten CSA mit anderer Permutationstabelle

… sagt die KI …

Wir sollten beim Wording CSA-ALT bleiben. Im Code fällt auch nicht 1x der Marketing-Name.
 
Zuletzt bearbeitet:
Ich habe immer noch das Tonproblem. (Zgemma H17) wundert mich, das es sonst keiner hat. Die Box ist ja nicht die Einzige, mit BCM 7251s.
Sobald ich auf einen anderen Slot gehe, ohne SoftSCA, kommt es nicht zu diesem Tonaussetzern.
 
Mach bitte nochmal ein Log mit der aktuellen SoftCSA Version. Hast du das bei StreamRelay auch?
 
ein Log mit der aktuellen SoftCSA Version
Vorführeffekt?
  • 2026/01/27 18:11:42 38FBDDB6 c (ecm) DVBApi (P: 098D:0071: #CW=0000000000000000CF157F212983BB0C:010241E38D61BACA9CFDB70A9DF9C1D8 HOP:): found (252 ms) by cs378x-Raspberry - History HD
  • 2026/01/27 18:11:50 38FBDDB6 c (ecm) DVBApi (P: 098D:0071: #CW=CFD3E5280368E43B0000000000000000:B352BA740647A430F486BD9366EFF47D HOP:): found (534 ms) by cs378x-Raspberry - History HD -hier ein Aussreisser, und ab da kein Ton mehr -Bild läuft weiter
  • 2026/01/27 18:11:56 38FBDDB6 c (ecm) DVBApi (P: 098D:0071: #CW=0000000000000000F7882A4FA119A663:F4B0727F7B7F7E3D719FE474DCD3F220 HOP:): found (252 ms) by cs378x-Raspberry - History HD
Einmal Umschalten und Ton ist wieder da. Ohne SoftCSA (OATV7.6.0 alles I.O.
Du musst Regestriert sein, um das angehängte Bild zusehen.
 

Anhänge

Du musst angemeldet sein, um die Anhangsliste zu sehen.
Zuletzt bearbeitet:
Ich habe einen Fix, der hoffentlich hilft. Devel-Feed update pending ...
Könnte dir auch via PN ein e2 ipk zur Verfügung stellen.
 
Das letzte Update macht bei meiner Vu+Uno4kSE Probleme. Meine Vu+Zero4K läuft mit Devel 7.6.1.34 vom 26.01.2026 ohne aussetzter. Die Uno stottert immer mal, das es aber auch stört.


Gesendet von iPhone mit Tapatalk
 
Das Update hat meine Einstellung von asynchronous auf synchronous geändert auf der sf8008, hab's jetzt auf automatisch gestellt.

Ich denke, da sich hier der Standard geändert hat, war meine Einstellung vorher der Sonderfall, der jetzt als synchronous gemappt ist?
 
Um @WXbet sein Post zu ergaenzen:

Bei CSA (und auch alt CSA) ist es so das das CW im Algo intern 2 mal verwendet wird nach einander, der sogenannter Block Cipher und der sogenannter Stream Cipher (Cipher kann man uebersetzen als Ent/Verschluesselungsalgorithmuss). Reihenfolge haengt davon ab ob man ver oder entschluesselt. Beide Cipher Verschluesseln den Stream anders. Er werden 2 Cipher verwendet als Redundanz falls doch mal eins der beiden irgendwie sich als unsicher herausstellen sollte. Bei klassischem CSA ist der genutzte Key bei beiden Ciphers Identisch, naemlich das originale CW. Klassische Hardware Decoder haben bei der Schnittstelle darum einfach nur 1x 8 byte Key zum setzen (+Schnittstelle zum Stream).

Bei CSA-Alt ist es so das der Stream Cipher immer noch das originale CW nutzt...aber beim Block Cipher gibt es eine bit Permutation bei manchen Bytes vom CW. Das Problem ist aber das die Hardware Dekoder wie gesagt nur das eine 8 Byte CW bekommen koennen und nichts wissen von Permutationen fuer den Key vom Block Cipher (und vorne rein kann man die Permutation nicht anwenden weil dann ist der Key vom Stream Cipher ja nicht mehr richtig). Wenn der Key vom Stream und Block Cipher separat gesetzt werden koennten waere es kein Problem..aber das ist halt typisch nicht vorgesehen durch die HW (bestimmt schon bei den Receivern von Sky). Deswegen braucht es also die SW Dekodierung wo die Anpassungen gemacht werden. Das wurde erst geloest mit Streamrelay, wo der Verschluesslte Stream ueber http Weitergeleitet und der entschluesselte ueber http abgespielt wurde (von daher auch der Name Streamrelay wo der Stream umgeleitet wird). Jetzt wurde die Arbeit gemacht das direkter zu machen.

Und ich staune jeden Tag wieder was @WXbet und seine Kollegen hier leisten...das wird hier nicht nur mal eben als PoC gemacht, sondern im Schnelltempo fertigentwickelt (Bugs sind oft innerhalb einer Stunde behoben) und das fuer alle Boxen...habe das schwer unterschaetzt das das ganze so kompliziert ist um auf (eventuell mit wenige Ausnahmen wegen Treiber) allen Boxen und mit allen Features gut hin zu bekommen.
 
Zurück
Oben