Lest mal die alten Sat Threads, da steht das alles schon 100mal drin, die NDS Kabelkarten verhalten sich nicht anders. Mode 10 ist AES128 ECB (also 128 Bit key) und Mode 02 ist TDES-ABA (also 112 Bits effektiv) ECB. Beides ist für Otto Normal nicht zu brechen. Das ist von der Sat Welt alles schon lange bekannt, man muss das Rad also hier nicht neu erfinden.
Aber beim Entschlüsseln geht OSCAM auf 3DES. Vielleicht ein Fehler meiner Binaries?
Laut aktuellem Code sollte der da in den AES Ast abbiegen und es sollte nicht 3DES da stehen...
Denn beim Tag 56 sind Einträge vorhanden.
2023/05/01 14:18:31 72DEEFDA r (reader) SlotUntenG02 [videoguard2] Decrypted payload
2023/05/01 14:18:31 72DEEFDA r (reader) D7 AA 7B F0 AA 49 36 2D 00 00 00 38 00 01 22 02
2023/05/01 14:18:31 72DEEFDA r (reader) 01 8B 56 08 A1 F1 B5 DE A1 B0 20 1E 45 03 40 00
2023/05/01 14:18:31 72DEEFDA r (reader) 80 2B 02 9C 8D
2023/05/01 14:18:31 72DEEFDA r (reader) SlotUntenG02 [videoguard2] classD3 ins54: Tag55_01 = 8B, CW-overcrypt may not required
2023/05/01 14:18:31 72DEEFDA r (reader) SlotUntenG02 [videoguard2] classD3 ins54: CW is crypted, trying to decrypt unique pairing mode 0x8B
2023/05/01 14:18:31 72DEEFDA r (reader) SlotUntenG02 [videoguard2] crypted CW is: 0000000000000000D7AA7BF0AA49362D
2023/05/01 14:18:31 72DEEFDA r (reader) SlotUntenG02 [videoguard2] use k1(3DES) for CW decryption in unique pairing mode
2023/05/01 14:18:31 72DEEFDA r (reader) SlotUntenG02 [videoguard2] decrypted CW is: 0000000000000000CFFE2D597450A253
2023/05/01 14:18:31 72DEEFDA r (reader) SlotUntenG02 [videoguard2] cardreader_do_ecm: after csystem->do_ecm rc=1
2023/05/01 14:18:31 72DEEFDA r (reader) SlotUntenG02 [videoguard2] cardreader_do_ecm: ret rc=1
2023/05/01 14:18:31 72DEEFDA r (reader) SlotUntenG02 [videoguard2] cardreader_process_ecm: cardreader_do_ecm returned rc=1 (ERROR=0)
2023/05/01 14:18:31 72DEEFDA r (reader) SlotUntenG02 [videoguard2] ecm hash: 25DFA6E836CB1B14D152F8A2A433A998 real time: 43 ms
2023/05/01 14:18:31 7F52D96C c (ecm) dvbapi (09EF@000000/0697/006E/A7:25DFA6E836CB1B14D152F8A2A433A998:0F06000000000000: found (46 ms) by SlotUntenG02 - Sky Atlantic HD (lg)
PS:
Hab den Fehler gefunden. Habe OSCAM r11715. Dort war AES in reader-videoguard2.c noch nicht implementiert...
Nun muss ich mal schauen, wo ich für meine alte Krücke noch ein aktuelles OSCAM Binary herbekomme...
2023/05/01 15:23:19 3C97AE25 r (reader) 01 8B 56 08 EA 22 70 E7 C2 00 DC 2A 45 03 40 00
2023/05/01 15:23:19 3C97AE25 r (reader) 80 2B 02 9C 8D
2023/05/01 15:23:19 3C97AE25 r (reader) SlotUntenG02 [videoguard2] classD3 ins54: Tag55_01 = 8B, CW-overcrypt may not required
2023/05/01 15:23:19 3C97AE25 r (reader) SlotUntenG02 [videoguard2] classD3 ins54: CW is crypted, trying to decrypt unique pairing mode 0x8B
2023/05/01 15:23:19 3C97AE25 r (reader) SlotUntenG02 [videoguard2] crypted CW is: 575EE5B8D778AB0CEA2270E7C200DC2A
2023/05/01 15:23:19 3C97AE25 r (reader) SlotUntenG02 [videoguard2] use k1(AES) for CW decryption in unique pairing mode
2023/05/01 15:23:19 3C97AE25 r (reader) SlotUntenG02 [videoguard2] decrypted CW is: 536FB10BAFACBAFB4675D59AEA2EADEA
2023/05/01 15:23:19 3C97AE25 r (reader) SlotUntenG02 [videoguard2] cardreader_do_ecm: after csystem->do_ecm rc=1
2023/05/01 15:23:19 3C97AE25 r (reader) SlotUntenG02 [videoguard2] cardreader_do_ecm: ret rc=1
2023/05/01 15:23:19 3C97AE25 r (reader) SlotUntenG02 [videoguard2] cardreader_process_ecm: cardreader_do_ecm returned rc=1 (ERROR=0)
2023/05/01 15:23:19 3C97AE25 r (reader) SlotUntenG02 [videoguard2] ecm hash: 964D93F48A80D403287CDA9CE3551472 real time: 44 ms
2023/05/01 15:23:19 5BA8F907 c (ecm) dvbapi (09EF@000000/0697/006E/A7:964D93F48A80D403287CDA9CE3551472:0F06000000000000: found (45 ms) by SlotUntenG02 - Sky Atlantic HD (lg)
Man möge mir verzeihen wenn ich so dämlich Frage oder es irgendwo bereits beantwortet wurde. Und ja BF ist nicht möglich.
1. Der eCW ist 32Byte lang, wahrscheinlich AES-128-EBC, verschlüsselt.
2. Der dCW ist dann auch 32Byte lang.
3. Für den CW Payload werden dann einfach die letzten 16Byte vom dCW abgeschnitten.
Kann dies überhaupt in der Form funktionieren?
2023/05/01 14:43:01 30D5C79D r (reader) internal [videoguard2] classD3 ins54: CW is crypted, trying to decrypt unique pairing mode 0x83
2023/05/01 14:43:01 30D5C79D r (reader) internal [videoguard2] crypted CW is: 003ACFB67C5C****8A5ACCC9FF6B****
2023/05/01 14:43:01 30D5C79D r (reader) internal [videoguard2] use k1(AES) for CW decryption in unique pairing mode
2023/05/01 14:43:01 30D5C79D r (reader) internal [videoguard2] decrypted CW is: C0220188FD99253C373148521E451604
2023/05/01 14:43:01 30D5C79D r (reader) internal [videoguard2] cardreader_do_ecm: after csystem->do_ecm rc=1
2023/05/01 14:43:01 30D5C79D r (reader) internal [videoguard2] cardreader_do_ecm: ret rc=1
2023/05/01 14:43:01 30D5C79D r (reader) internal [videoguard2] cardreader_process_ecm: cardreader_do_ecm returned rc=1 (ERROR=0)
2023/05/01 14:43:01 30D5C79D r (reader) internal [videoguard2] ecm hash: D4AD4337107F5EA6F80CD083185576B9 real time: 142 ms
2023/05/01 14:43:01 019BF9BA c (ecm) dvbapi (098E:0017#LEN=9F#ECM=D4AD4337107F5EA6F80CD083185576B9#CW=0000000000000000C02201E3FD9925BB): found (142 ms) by internal - Sky Krimi HD
Die Sache noch weiterführen..
Den CW Payload via CAID 1838 ermitteln.
Sprich ich habe..
Wenn der CW nur die ersten 16Bytes vom dCW ist, dann fehlt doch der Rest um überhaupt einen theoretischen BF zu machen.
Mit dem vorliegenden Schlüsselmaterial kann es nicht funktionieren.
Der eCW ist 16 Bytes lang, nicht 32. Du meinst vielleicht die Nibbles. Ein Byte besteht aus 2 hex Nibbles. Jedes Nibble hat 4 Bits.
In den AES werden alle 16 Bytes reingesteckt, die ersten 8 und die aus Tag 56 und dann der K1 dazu.
Und es kommen wieder 16 Bytes raus. Das müssten dann CW0 und CW1 sein, Reihenfolge entsprechend Marker 80/81.
Folglich brauchst Du auch das passende 16 Byte dCW. Alternativ einen BF schreiben (BF geht ja nicht in endlicher Zeit), der nur die 8 Bytes checkt.
Vielleicht irre ich mich auch dass in Tag 56 das zweite eCWx steckt. Dann ist es nur eine Zufallszahl.
Und wenns nur ne Zufallszahl ist, dann kann man eh nicht mit z.B. hashcat ran gehen (oder kann man das ausmaskieren?). Die decrypted Zufallszahl gibts ja ned real.
Also eigenen BF Algo schreiben.
Aber das bekommen wir erst sicher raus, wenn jemand den K1 hat
BTW,
hashcat schafft beim DES auf meiner 3090 ca. 68000 MH/s. Also worst case ca. 12 Tage zum Knacken und im Schnitt 6 Tage.
48 Bit würde ich in 1h 10 min schaffen (CSA). Von den 7 Sekunden weit entfernt
Noch was:
Die Änderung in OSCAM bzgl. AES ist schon recht alt (16.12.2022). Wer weiß, ob das überhaupt schon wer irgendwo am Laufen hatte.
Kann es denn kryptografisch überhaupt funktionieren vom 16Byte dCW lediglich eine Untermenge zu verwenden?
Dieser CW0 oder CW1 passt auch noch zum CW von einen anderen CAS. In dem Falle 1838 (Nagra).
Ja, warum denn nicht. Den Rest halt auskommentieren. Man bricht ab, wenn die 8 Bytes, die einen interessieren, passen.
Aber das bedeutet nicht, dass man den K1 dann hat. Man hat nur einen Kandidaten. In dem Fall gibt es dann 2^64 Kandidaten, die man alle finden und testen muss.
Also wenn die anderen 8 Bytes ne Zufallszahl oder Salt sind, dann wäre das ganz schön hinterf*tzig.
Ich könnte mir vorstellen, dass man immer beide CWx hat. Sonst wären die Kanalumschaltzeiten ganz schön lang.
Ja gut, aber dann muss da mal was gelaufen sein und jemand hatte den K1 dazu - wo auch immer der herkam. Schien ja doch irgendwie möglich zu sein....
Mal ne generelle Frage:
Kann man über OSCAM der Karte irgendwie ein zuvor kopiertes ECM nochmal unterjubeln, sodass man ein entsprechendes Log bekommt?
Wenn ich das als EMM schreibe, steht nix im Log.
Könnte bitte jemand kurz die Sender nennen, die seit dem 18.04. noch hinzu gekommen sind, damit ein Update auf der ersten Seite erfolgen kann.
Vielen Dank.
Bei mir gehen folgende Sender auch nicht mehr, die in der Liste noch fehlen (im OSCAM Log steht jeweils, dass das CW crypted ist):
Sky One HD (der von VF geht noch)
Universal TV HD (der von VF geht noch)
Sky Atlantic HD
Sky Replay HD
Sky Cinema Fun