SKY Pairing im Kabelnetz - LABERTHREAD - war ja auch klar

[R2D2_4711]

Die CWs haben hier nur 6 relevante Bytes. Macht 48 Bit für BF, dummerweise alle 7 Sekunden.

Jau, und es gab schon diverse Ansätze mit Rainbow-Table und 7,9TB Lookup-Daten

Unmöglich ist es nicht:

Sie müssen registriert sein, um Links zu sehen.

 

[adas]

Andere situation, wir "werfen" N raus, sind doch SKY sender.

Wie lautet der vertrag zwischen den beiden ist mir nicht bekannt.

Cau Adas

 

[navajo2]

Die Gedanken sind schon mal richtig wenn wir das ganze mathematisch betrachten und wir das Ergebnis ja haben. Fehlt nur die Zahl dazwischen.

 

[glaubichnicht]

AES-128, AES-192, AES-256, AES-CBC

Ab wann sind die Module raus ?

 

[DVB-T2 HD]

Wir sind hier im Kabel. Richtig?

Die CWs haben hier nur 6 relevante Bytes. Macht 48 Bit für BF, dummerweise alle 7 Sekunden.

Wenn das bei den Sky-Programmen im KabelTV so ist, dann Rainbow-Tabellen in Gemeinschaftsarbeit erstellen. Alleine bräuchte man da viele Monate bis Jahre, wenn man das erfolgreich machen wollte.

Jau, und es gab schon diverse Ansätze mit Rainbow-Table und 7,9TB Lookup-Daten

Mit 8TB Rainbow-Tabelle wird man zwar mal was zu sehen bekommen, aber mit vielen Aussetzern beim CW-Wechsel muss man immer noch leben (wollen). So ab einer doppelt so großen Rainbow-Tabelle wird’s dann brauchbar. Müssen aber sehr schnelle PCIe SSD-Speichermedien für die Rainbow-Tabellen sein. Zur Erzeugung der Rainbow-Tabellen braucht man außerdem Grafikkarten mit schnellem CUDA.

 

[cdrom]

Spoiler

Du musst angemeldet sein, um Medien zu sehen.

 

[scoppy]

und was heisst das jetzt für uns genau?

 

[adas]

Glitch

Cau Adas

 

[R2D2_4711]

Wenn das bei den Sky-Programmen im KabelTV so ist, dann Rainbow-Tabellen in Gemeinschaftsarbeit erstellen. Alleine bräuchte man da viele Monate bis Jahre, wenn man das erfolgreich machen wollte.



Mit 8TB Rainbow-Tabelle wird man zwar mal was zu sehen bekommen, aber mit vielen Aussetzern beim CW-Wechsel muss man immer noch leben (wollen). So ab einer doppelt so großen Rainbow-Tabelle wird’s dann brauchbar. Müssen aber sehr schnelle PCIe SSD-Speichermedien für die Rainbow-Tabellen sein. Zur Erzeugung der Rainbow-Tabellen braucht man außerdem Grafikkarten mit schnellem CUDA.

CSA ist der DVB Standard Scrambler (Hardware Scrambler) - auch bei Sat. Nur haben die Himmlischen den vor 'ner Weile mal eben gegen einen anderen ausgetauscht (ICAM). Die freien Boxen müssen den nun in Software emulieren, was einiges an Rechenzeit erfordert und die älteren Boxen mit den betagten CPUs sind damit überfordert.

Die Rainbow Methode funktioniert nur, wenn man den Plain-Text kennt. Hier hat man es sich zu Nutze gemacht, dass in den MPEG2 Streams oft viele Null-Padding-Blöcke auftauchen. Das kann man daran erkennen, dass mindestens 2 aufeinanderfolgende verschlüsselte 184 Byte Blöcke identisch sind. Hier kommt dann die Rainbow-Tabelle ins Spiel. Wenn man das CW dann hat, kann man den Stream für die Validitätsdauer entschlüsseln. Zu Aussetzern muss es nicht kommen, wenn man den Stream entsprechend zwischenspeichert.

Aber ich denke, dass man bei MP4 diese Null Blöcke nicht mehr so vorfindet.
Man kann zwar noch auf den Header gehen, dessen erste (ich glaub 3, = 24 Bit) Bytes immer identisch sind, aber das macht es nicht leichter. Es würden bei BF zu viele Kandidaten gefunden.
Damit fliegt der Rainbow-Ansatz wieder raus (bzw. die Tabellen werden ungemütlich groß)...

CUDA wäre nicht das Problem. Ist rel. leicht zu erlernen mit dem SDK von Nvidia. Hab ich auch schon gemacht, um bei TeamSpeak 3 den Level zu erhöhen. Das geht damit relativ fix mit über 4 Milliarden SH1 Hashes/s auf einer 3090.
Aber das reicht trotzdem nicht für einen vollständigen 48-Bit BF (2^48 = 281.474.976.710.656) in angemessener Zeit. Man kommt bei meinem SH1-Fall dann auf ca. 48 Stunden Rechenzeit.
Der CSA scheint etwas trivialer als SH1 zu sein. Man wird vermutlich einen höheren Durchsatz bekommen, aber das wird auch nicht reichen.

PS:
Man könnte einfach mal versuchen, den CSA in CUDA zu implementieren und dann mal schauen, auf welche BF-Rate man kommt...
Bei 3 bekannten Bytes bekäme man 16,7Mio Kandidaten. Bei denen müsste man dann in einer längeren Sequenz schauen, ob ein sinnvoller Stream hinten raus kommt.

Haha, es gibt sogar 'nen CSA PlugIn für den VLC Player mit vollständigem Quellcode. Der Link is im CSA wiki.

Sie müssen registriert sein, um Links zu sehen.

Dann kanns ja losgehen

Es wird immer besser. Hier eine fertige BF-Hardware-Lösung mit FPGAs von Xilinx:

Sie müssen registriert sein, um Links zu sehen.

In einem ersten Schritt werden alle 2^48 Möglichkeiten durchprobiert und die Candidates gespeichert, die als Plain-Text in den ersten 3 Bytes 0x000001 liefern.
Dann wird für alle Candidates mit dem nächsten 184 Block geschaut, ob wieder 0x000001 rauskommt. Dadurch reduziert sich die Zahl der Candidates.
Am Ende ist nur noch ein Candidate übrig.

Autsch...
Man braucht 8715 Stück Artix 7 FPGAs für ein Zeitziel von 10 Sekunden, einen neuen Stromanschluss und keine Gas-Heizung mehr...

10 seconds goal, Artix 7 190 MHz, 148145 BF-Cores, 8715 FPGAs, 1’688’096 USD

Hat jemand 1,7 Mio US Dollar übrig für ein "kleines" Machbarkeitsprojekt?

 

[yGIQR2GJ]

Kurze Verständnis Frage:

Bei der V13 wurde eCW:dCW als je 16Byte Hex String benutzt. Ein DES String ist nun 8Byte lang.
DES Key + IV = 16Byte ?!

Sie müssen registriert sein, um Links zu sehen.

Sie müssen registriert sein, um Links zu sehen.

(Mode 14000)

 

[adas]

Das sind aber alles "trocken" übungen.

Cau Adas

 

[R2D2_4711]

Ja, dann lasst uns mal 'nen Custom Chip mit 300.000 BF-Cores designen... Kein ASIC, 'nen richtigen Chip.
Dann bauste den in ein CI Modul rein

Hey, wenn wir den Chip mit 1,9GHz takten anstatt mit 190MHz wie bei dem Xilinx, brauchen wir für ein 5s Ziel nur 30000 cores.

Bevor der CSA2 „Stream Hack“ in
machbare / bezahlbare Bereiche für Privatleute kommt wird das System längst auf CSA3 oder AES Scrambling umgestellt sein.

Es ist ja nicht so als hätte sich damit hier noch keiner befasst mit ner schnellen GPU kann man 48bit CWs auch in unter 2 Tagen errechnen. Aber hilft halt nix wenn der Intervall 7 Sekunden ist.

Könnte mir vorstellen, dass es sogar schneller geht. In der Bachelor-Arbeit hat er erwähnt, dass an den ersten 8 Bytes Plain-Text nur die ersten 16 Bytes Cypher-Text aus dem 184-Bytes Block beteiligt sind. Damit muss man den CSA nicht vollständig durchlaufen lassen.

Kurze Verständnis Frage:

Bei der V13 wurde eCW:dCW als je 16Byte Hex String benutzt. Ein DES String ist nun 8Byte lang.
DES Key + IV = 16Byte ?!

Sie müssen registriert sein, um Links zu sehen.

Sie müssen registriert sein, um Links zu sehen.

(Mode 14000)

Der DES wird so oft ausgeführt, bis alles ent-/verschlüsselt ist. Also hier 2 mal für 16 Bytes.
Der IV ist glaub ich immer 0, wenn ich das richtig gesehen hab in OSCAM.

 

[parasonic]

Jetzt hat irgendjemand meinen Post und die von @R2D2_4711 in einen zusammengeworfen… sehr komisch, aber egal.

Da das ecw ja immer nur ein Block ist, kommt CBC doch eh nicht zum Tragen. Also ja es ist IV = 0 aka ECB mode.

 

[R2D2_4711]

Hab' mich gerade noch ein bissel mehr mit K1 beschäftigt, nachdem ich meine BoxID und ins7e und einen dummy K1 eingetragen hab.
Ergebnis: 90 20 und 55 01 88 (Tag 55) für non-Overcrypt Sender. => OK
Wenn ich auf einen der OC Programme schalte, kommt für Tag 55_01 nicht mehr 88, sondern 8B (Binär: 1000 1011).
Bit0 == 1 bedeutet: CW ist cryted
Bit1 == 1 bedeutet: Unique Pairing
Alle 8 Bytes von Tag 56 = 0 bedeutet: kein AES, da die 8 bytes dort für AES benötigt würden. Steht aber nix drin.
OSCAM geht also auf 3DES.
Der BF-Aufwand für 3DES mit 2 Keys ist aber effektiv nur 2^57 und nicht 2^112.
Weil: Man-In-The-Middle Attacke möglich ist
Aber wohin mit zwei 2^56 Hashmap-Einträgen á 8 Bytes?
Wenn's wirklich "nur" 3DES ist und Cypher&Plain bekannt sind (Ja, weil Pärchen bestimmbar sind), wäre es BF-bar.

Quelle:

Sie müssen registriert sein, um Links zu sehen.

PS:
Vergesst das mit den bekannten Pärchen... wir kommen ja nicht an an dCW ran, weil noch keiner den K1 hat...

 

[DarkStarXxX]

Natürlich kommt man an das dCW ran.