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?