R2D2_4711
Newbie
- Registriert
- 24. November 2018
- Beiträge
- 14
- Reaktionspunkte
- 535
- Punkte
- 98
Naja, doch. Bei MPEG2 hatte man zumindest bei einigen (wenigen) Programmen "früher" null Paddings direkt im MPEG Stream eingebaut. Ich weiß das mit Sicherheit, weil ich mal ein nicht allzu unbekanntes Programm für die DBox1 geschrieben hatte, mit dem man aufnehmen konnte (ja, ich war das 
). Vor dem Multiplexen habe ich dann diese Null-Bytes rausgeworfen und in einem Zähler-Feld konnte man sehen, wieviel entfernt wurde. Diese Sicherheitslücke wurde dann aber bekannt und man hat das dann bleiben lassen und das Padding in das Adaption-Field eingebaut, welches nicht verschlüsselt wird. @Miese.Ratte hat das schon richtig erklärt.
Gesichert ist aber Folgendes:
Momentan arbeite ich an dem CUDA Programm, was auf den bekannten Plain-Text 00 00 01 geht. Das könnte heute "ablaufbar" werden.
Danach weiß ich, wie hoch die CW-Rate voraussichtlich sein wird und wie lange es dauern wird. Ich gehe aufgrund einer groben Hochrechnung aktuell im Worst Case von ca. 13 Stunden aus (RTX 3090, bei 4090 vermutlich in unter 6 Stunden.).
Bei der Gelegenheit könnte man sich aber mal ein paar Statistiken bzgl. Regelmäßigkeiten in der Payload anschauen. Vielleicht findet man was, bei dem Rainbow funktionieren könnte.
Wir kommen aber nicht um ein Selbststudium einer Rainbow-Attacke herum. Man muss genau verstehen, wie es funktioniert und dann überlegen, ob man das anwenden kann.
Also ich weiß das aktuell noch nicht. Die Colibri-Tables können wir sehr wahrscheinlich vergessen.
Mein CUDA-Programm könnte evtl. auch nützlich sein, zu einem eCW das dCW zu finden. Wer weiß, wozu das noch gut sein könnte...
). Vor dem Multiplexen habe ich dann diese Null-Bytes rausgeworfen und in einem Zähler-Feld konnte man sehen, wieviel entfernt wurde. Diese Sicherheitslücke wurde dann aber bekannt und man hat das dann bleiben lassen und das Padding in das Adaption-Field eingebaut, welches nicht verschlüsselt wird. @Miese.Ratte hat das schon richtig erklärt.Gesichert ist aber Folgendes:
- Der Start eines jeden PES-Pakets fängt mit 00 00 01 an.
Man pickt sich im TS-Stream also alle Pakete raus, deren PUSI-Bit im TS-Header 1 ist.
Das signalisiert den Start des PES-Pakets. - Über ein paar dieser Start-Pakete kann man per BF mit der Komplexität 2^48 das CW bestimmen:
Man benötigt nur die ersten 16 Bytes der Cypher-Payload, um die ersten 8 Bytes Plain-Payloads zu erhalten.
Es ist also nicht nötig, die ganze "Wurst" durch den CSA "durchzudrücken".
Die ersten 3 Bytes prüft man auf 00 00 01. Wenn es matcht, checkt man diesen Kandidaten mit den nächsten PES-Paketen.
Wenn immer 00 00 01 rauskommt, hat man das CW zu 99.9999999999999999% gefunden.
Momentan arbeite ich an dem CUDA Programm, was auf den bekannten Plain-Text 00 00 01 geht. Das könnte heute "ablaufbar" werden.
Danach weiß ich, wie hoch die CW-Rate voraussichtlich sein wird und wie lange es dauern wird. Ich gehe aufgrund einer groben Hochrechnung aktuell im Worst Case von ca. 13 Stunden aus (RTX 3090, bei 4090 vermutlich in unter 6 Stunden.).
Bei der Gelegenheit könnte man sich aber mal ein paar Statistiken bzgl. Regelmäßigkeiten in der Payload anschauen. Vielleicht findet man was, bei dem Rainbow funktionieren könnte.
Wir kommen aber nicht um ein Selbststudium einer Rainbow-Attacke herum. Man muss genau verstehen, wie es funktioniert und dann überlegen, ob man das anwenden kann.
Also ich weiß das aktuell noch nicht. Die Colibri-Tables können wir sehr wahrscheinlich vergessen.
Mein CUDA-Programm könnte evtl. auch nützlich sein, zu einem eCW das dCW zu finden. Wer weiß, wozu das noch gut sein könnte...
Zuletzt bearbeitet:
