Dies ist eine mobil optimierte Seite, die schnell lädt. Wenn Sie die Seite ohne Optimierung laden möchten, dann klicken Sie auf diesen Text.

SKY Pairing im Kabelnetz - LABERTHREAD - war ja auch klar

@Miese.Ratte Danke.

debug auf "2"

bei 098e =>
ecm 80 70 (even, cw first 16bytes)
ecm 81 70 (odd, cw last 16bytes)



bei 1838 =>
ecm 80 30 (even, cw first 16bytes)
ecm 81 30 (odd, cw last 16bytes)


Und das Ganze mit 098E (overcrypting) und 1838 als dCW Lieferer.

 
Zuletzt bearbeitet von einem Moderator:
Das gesamte Bitcoin Netzwerk schafft im Jahr 2^94 AES-256 Hashes...
Wir brauchen "nur" 2^112 3DES ...


Für eine Karte...
 
Mir wurde gesagt, die CWs sind auf einen Kanal gleich. Egal welche CAID ob 1838 oder 098E.

Dem CSA ist es ja vollkommen egal, wie das zum Entschlüsseln der Inhalte notwendige CW übertragen wurde. Wäre das nicht so, müssten ja je CAID verschieden verschlüsselte Inhalte gesendet werden. Bei zwei CAIDs bräuchte man dann die doppelte Bandbreite dafür. Das macht so keinen Sinn.
 

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.
 

Ich bekomme "83" von der Karte.

tag55: 55 01 83
tag56: 56 08 2E 5E EE CC 43 9A

tag55[2]: 83 => 10000011 (right to left)
bit0: 1 (bit0==1 CW is crypted)
bit1: 0 1 (bit1==1 unique Pairing, bit1==0 generic pairing)
bit2: 0 (bit2==0)
bit3: 0 (bit3==1 CW-Overcrypt may not required)


 
Zuletzt bearbeitet von einem Moderator:
Welcher Sender? Welche Karte? Es könnte evtl. sein, dass Sky einige Kunden mit AES "beglückt"...

Bei den Bits ist ein kleiner Denkfehler. Bit 0 ist ganz rechts
tag55[2]: 83 => 1000 0011
bit0: 1 (bit0==1 CW is crypted)
bit1: 1 (bit1==1 unique Pairing, bit1==0 generic pairing)
bit2: 0 (bit2==1, old dimeno_PostProcess_Decrypt) // (Weitere) AES Verschlüsselung im Nachgang bzw. alternativ, wenn Bit0 == 0 ist
bit3: 0 (bit3==1 CW-Overcrypt may not required), gibt nur diese Meldung aus.


Hab da noch ne Idee, die zu verifizieren wäre:
Wenn (3)DES angefordert wird, hängt es davon ab, ob K1 8 oder 16 Bytes lang ist.
Wenn 8 Byes, wäre es nur DES mit 2^57. Das ließe sich mal eben schnell BF-en.
Das könnte man mal verifizieren. Dauert ja nicht so lange. Wenn nix gefunden wird, ist es mindestens 3DES.
Wenn was gefunden wird, kann es Zufall sein. Dann nochmal mit 2. Pärchen verifizieren.

Diese Bits in Tag 55 sind ja auch nur Try-And-Error. Prinzipiell kann es alles sein.
Hat jemand mal in seinem Zuordner (der ist das mit ins7e, und der Kennung, oder??) geschaut, ob die Kennung für 3DES oder AES drin ist?
 
Zuletzt bearbeitet von einem Moderator:
Hast Recht.

Sender ist "Sky Krimi HD" (098E:0017).
Karte ist von 2015 mit ROM "KWTV-10T1".
 
@yGIQR2GJ: Nutze bitte die Spoiler-Funktion um Logfiles usw. zu posten und nicht Zitieren. Das macht deine Einträge deutlich übersichtlicher. Danke.
 

Die Länge des eCW wird von der Karte geliefert.

2023/05/01 10:14:10 6B5F81B2 r (reader) internal [videoguard2] Decrypted payload
2023/05/01 10:14:10 6B5F81B2 r (reader) BC F7 61 84 85 BE 99 05 00 00 00 3F 00 01 22 02
2023/05/01 10:14:10 6B5F81B2 r (reader) 00 80 0E 02 01 00 0F 04 00 00 00 00 20 04 00 00
2023/05/01 10:14:10 6B5F81B2 r (reader) 00 00 25 11 00 00 00 00 00 00 00 00 00 00 00 00
2023/05/01 10:14:10 6B5F81B2 r (reader) 00 00 00 00 00 55 01 83 56 08 0B 0C 44 56 80 BF
2023/05/01 10:14:10 6B5F81B2 r (reader) 68 5A
2023/05/01 10:14:10 6B5F81B2 r (reader) internal [videoguard2] classD3 ins54: CW is crypted, trying to decrypt unique pairing mode 0x83
2023/05/01 10:14:10 6B5F81B2 r (reader) internal [videoguard2] crypted CW is: BCF7618485BE99050B0C445680BF685A

Du kannst in der "reader-videoguard2.c:1372" den Check umgehen, damit nur die ersten 8Byte vom eCW genutzt werden.
Ob dies überhaupt Sinn macht. :-/

[..]
if( reader->caid != 0x98E && (buff_56[0]|buff_56[1]|buff_56[2]|buff_56[3]|buff_56[4]|buff_56[5]|buff_56[6]|buff_56[7]) != 0)
[..]
2023/05/01 10:54:55 66CCDE29 r (reader) internal [videoguard2] Decrypted payload
2023/05/01 10:54:55 66CCDE29 r (reader) 08 30 A0 06 29 0F 7C E7 00 00 00 3F 00 01 22 02
2023/05/01 10:54:55 66CCDE29 r (reader) 00 80 0E 02 01 00 0F 04 00 00 00 00 20 04 00 00
2023/05/01 10:54:55 66CCDE29 r (reader) 00 00 25 11 00 00 00 00 00 00 00 00 00 00 00 00
2023/05/01 10:54:55 66CCDE29 r (reader) 00 00 00 00 00 55 01 83 56 08 B3 26 E3 2F 06 58
2023/05/01 10:54:55 66CCDE29 r (reader) 57 E6
2023/05/01 10:54:55 66CCDE29 r (reader) internal [videoguard2] classD3 ins54: CW is crypted, trying to decrypt unique pairing mode 0x83
2023/05/01 10:54:55 66CCDE29 r (reader) internal [videoguard2] crypted CW is: 00000000000000000830A006290F7CE7
2023/05/01 10:54:55 66CCDE29 r (reader) internal [videoguard2] use k1(3DES) for CW decryption in unique pairing mode


Diese Bits in Tag 55 sind ja auch nur Try-And-Error. Prinzipiell kann es alles sein.
Hat jemand mal in seinem Zuordner (der ist das mit ins7e, und der Kennung, oder??) geschaut, ob die Kennung für 3DES oder AES drin ist?
Meinst du die Uniq EMMs?

Mit Kennung meinst du?
> 00011010050002101005 (AES)
> 00010202030002020203 (TDES)
 
Die Zuordnung entscheidet ob die Karten AES oder TDES als CWE machen. Man erkennt den Modus an der Karten-Antwort auf die ins7423 (sieht man z.B. im Oscam Log beim Readerstart bei erhöhtem Debuglevel).

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.

Solche Spirenzchen wie bei der V13 (wo der TDES mode 02 nur ein simples DES ist) gibt es bei den Kabelkarten scheinbar nicht, das wurde ausprobiert, ohne Erfolg.

Also entweder glitcht ihr Eure Keys „mit Gewalt“ (entweder mit viel Können, viel Geld, 300000 FPGAs und/oder anderen entsprechendem Equipment) aus Eurer Hardware raus, oder ihr müsst wie alle anderen halt ewig drauf warten. Das ist leider aktuell die Realität.

Interessant fände ich hingegen, rauszufinden, welche Kabelkarten eine TDES Zuordnung bekommen haben, und welche AES…? Hat das mit der gepaarten Hardware zu tun? Weil bei Karten die zu Q Boxen gehören, ist mir bisher immer nur AES Mode begegnet. Welche Karten haben denn TDES bekommen (also wo 55_01 83 oder 8B ist, aber 56_08 leer bleibt)…?
 
Zuletzt bearbeitet:
Ich bitte um etwas Verständnis. Ich hab kein SAT und ich verfolge auch nicht die unzähligen Threads und Posts über diverse Foren.
Ich beschäftige mich erst seit einer Woche damit, weil es mich interessiert.
Wenn schlussendlich der K1 Key unerreichbar in diesen Gurkenreceiver begraben bleibt, dann ist es so.

Zur Info.. die Karte habe ich mit dem Humax HD3000C (iHD PVR, ins7e beginnend mit 42 74 13 11) verheiratet.

2023/05/01 11:32:00 0D2BA27A r (reader) internal [internal] write to cardreader
2023/05/01 11:32:00 0D2BA27A r (reader) D3 74 23 00 26
[..]
2023/05/01 11:32:00 0D2BA27A r (reader) internal [internal] Decrypted payload
2023/05/01 11:32:00 0D2BA27A r (reader) 54 14 00 10 00 01 6B 6C 0F 85 C1 01 B4 E3 F9 3E

 
Meine G02 gehört zu einer Q und liefert 8B bei OC und 56_8 ist leer. Die Box wurde mir ca. Dezember zwangsaufgedrückt.
Interessant, da es 3DES zu sein scheint und nicht AES...

PS:
Karte lief schon ne Weile in Q und alles hell. D.h. Zuordner korrekt drauf. Vielleicht hab ich bald Pech und fange mir 'nen AES-Zuordner ein...
In DM8000 aber auch keine Probleme außer OC dicht. Hier alles geblockt und Aktivierer manuell geschrieben.
 
Zuletzt bearbeitet:
Im satbereich ist aber alles AES oder kann es dort auch 3DES sein?
 
Ja außer Motorvision und cartoonito oder?
 
Für die Nutzung dieser Website sind Cookies erforderlich. Du musst diese akzeptieren, um die Website weiter nutzen zu können. Erfahre mehr…