LABERTHREAD zum Thema: Umstellung der SAT-Verschlüsselung bei Sky (Geschlossen)

Aktuelles zur Änderung der Verschlüsselung seitens Sky

Sky fügt weiteres Sicherheitsfeature bei Verschlüsselung über Sat hinzu - Juli 2021

Sky hat alle Sender auf Sicherheitsfeatures umgestellt. - dazu wurde der Overcrypt-Mode von DES auf AES umgestellt. - dadurch ist ein neuer Key für die OScam notwendig. - diesen aber zu Brutforcen ist nun auch "unmöglich", weil nun auch 128bit Dadurch können die Sender nicht mehr per V13 und...

www.digital-eliteboard.com

Aktuelles zum Verhalten im Thema:​

LABERTHREAD zum Thema: Umstellung der SAT-Verschlüsselung bei Sky (Geschlossen)

Aktuelles zur Änderung der Verschlüsselung seitens Sky Du musst angemeldet sein, um das Element zu sehen. Aktuelles zum Verhalten im Thema: Du musst angemeldet sein, um das Element zu sehen. Du musst angemeldet sein, um das Element zu sehen.

www.digital-eliteboard.com

LABERTHREAD zum Thema: Umstellung der SAT-Verschlüsselung bei Sky (Geschlossen)

Aktuelles zur Änderung der Verschlüsselung seitens Sky Du musst angemeldet sein, um das Element zu sehen. Aktuelles zum Verhalten im Thema: Du musst angemeldet sein, um das Element zu sehen. Du musst angemeldet sein, um das Element zu sehen.

www.digital-eliteboard.com

 

[despino32]

Na dann

Die welche die den key haben werden es hier nicht preisgeben

 

[DarkStarXxX]

Was dir wohl entgangen ist, das die meisten eine V15 Karte haben.

 

[kautz8953]

Wenn man sich den ins bei der V13 anschaut.

Früher war 54 14 00 02 00 01 (14byte key) 00 01

Heute ist 54 14 00 10 00 01 (14byte key) 00 01

Die 00 10 wird dem keyladder am Anfang gegeben gefolgt von einem key der vermutlicherweise von der Hardware generiert wird. Darauf folgt der ins, der fängt bei V13 mit 00 01 an. Bei V14/15 aber mit 00 02

Das die 00 10 für aes zuerst kommt erscheint mir zumindest logisch wie eine Mitteilung von. Rechne bitte mit aes ich gebe dir jetzt die keys.

Die Frage ist einfach was sagt dieses 00 01 bei der V13 aus….

Was wird dem keyladder da mitgeteilt ?
Vlt das an dem key der V13 was anders ist als bei dem key der V14….

 

[RuckZuck]

Vielleicht ja, dass es in der key-Anwendung für die KLAD gewisse Anweisungen gibt zusätzlich zu AES-zwang!?

Edit:
Wer Ideen hat: ich habe noch eine aktive V13 und bin für Ideen / Dinge zum ausprobieren/ untersuchen offen.

 

[glaubichnicht]

Wieso dreht sich nun alles um die V13 mit AES Key ?
Habe ich was verpasst ?
Gibt es nun schon lauffähige V13 im Share

 

[streithausen]

Erbarmen für Raspi Nutzer:

Hier eine oscam (svn11704) mit
- sendcmd (THX an @Miese.Ratte )
- aes.patch (THX an @Youtube18 )

@Youtube18
Gegen welche SVN hattest Du den Patch getestet? ich hatte diesen leicht modifizieren müssen damit dieser auf 11704 passt.

@Miese.Ratte
Wenn READER_MERLIN definiert ist muss Dein Patch ebenfalls in oscam-work.h geändert werden.

Edith: Spoiler und Code entfernt, Dateianhang gelöscht, Link zur Datenbank gesetzt

nun im Downloadbereich

 

[Youtube18]

@streithausen
Der Download ist hier falsch, bitte in die Downloadsektion damit.
Da findet sich auch schon eine Raspi arm Version von mir mit nur dem AES Patch (arm-linux - oscam-1.20_svn11704-arm-linux-gnueabihf-ssl.zip)

Der Patch ist mit der aktuellsten 11704 gebaut.
Da musst du in der reader-videoguard2.c auch nichts anpassen, mit patch sollte alles problemlos durchlaufen.
Du sieht ja im Patch auch welche Zeiten rausgenommen werden und welche dazu kommen.
Kann mir nur lokale Änderungen vor dir vorstellen ...

Ich konnte den Patch auch problemlos auf z.B. die rev 11583 anwenden.
Der Overcrypt Teil kam ja Ende 2019 final rein und ist seither gleich ...
Und auch nur der wurde von mir angepasst

 

[kautz8953]

Wieso dreht sich nun alles um die V13 mit AES Key ?
Habe ich was verpasst ?
Gibt es nun schon lauffähige V13 im Share

Wenn ich mir so manche Zeiten anschaue stellt sich mir die Frage ob da nicht die V13 auf die 098D Gemappt wird. Bei Zeiten von 160-180ms für 098D . . . Steckt da nicht manchmal doch ne V13 hinter ?

 

[el_malto]

Stellt sich ja die Frage über wie viele Hops oder Caches die CWs geschickt werden...

 

[streithausen]

...
Du sieht ja im Patch auch welche Zeiten rausgenommen werden und welche dazu kommen.
...

Ja, nur hat dieses nach einem frischen SVN checkout oscam nicht gepasst ?!?

pi@[...] /tmp $ patch reader-videoguard2.c < aes.patch
patching file reader-videoguard2.c
Hunk #1 FAILED at 1244.
Hunk #2 FAILED at 1274.
Hunk #3 FAILED at 1369.
Hunk #4 FAILED at 1382.

ich habe es manuell eingepflegt und einen neuen diff erzeugt.

 

[RuckZuck]

Korrekt @el_malto und wie stark die Karte belastet ist.
Ist bei der V15 ja sehr wahrscheinlich aktuell

 

[navajo2]

Wenn ich mir so manche Zeiten anschaue stellt sich mir die Frage ob da nicht die V13 auf die 098D Gemappt wird. Bei Zeiten von 160-180ms für 098D . . . Steckt da nicht manchmal doch ne V13 hinter ?

(098D@000000/0263/000D/A0:68D6511A90F89F56B9CBC9C6C92C12F8): cache3 (48 ms) by xxx (C/2/2/3) - Sky Crime HD Du hast einfach einen schlechten Share

 

[Youtube18]

@streithausen
Wenn du den Sendcmd Patch zuerst anwendest klar, dann ist der Codestand nicht mehr gleich wie im 11704er SVN (der Sendcmd Patch greift auch in die reader-videoguard2.c ein) und mein Patch fährt gegen die Wand - ganz logisch
Bei mir frisches Oscam aus dem svn, funktioniert es 1A.

Spoiler

rev 11704:

root@raspberrypi4:/tmp/oscam/trunk# patch reader-videoguard2.c < aes.patch
patching file reader-videoguard2.c

rev 11583:

root@raspberrypi4:/tmp/oscam/trunk# patch reader-videoguard2.c < aes.patch
patching file reader-videoguard2.c
Hunk #1 succeeded at 1246 (offset 2 lines).
Hunk #2 succeeded at 1276 (offset 2 lines).
Hunk #3 succeeded at 1374 (offset 2 lines).
Hunk #4 succeeded at 1389 (offset 2 lines).

@kautz8953
Mehr auf die Zeiten als auf die Hops der Karten schauen
Ich kann dir auch einen Oscam Patch schreiben der jegliche Karten von deinem Server egal wie viele Hops die wirklich haben nach außen als Hop1 anzeigt.
Wie heißt es so schön in der Werbung: Alles eine Frage der Technik

 

[glaubichnicht]

(098D@000000/0263/000D/A0:68D6511A90F89F56B9CBC9C6C92C12F8): cache3 (7 ms) by xxx (L/2/2/3) - Sky Crime HD Du hast einfach einen schlechten Share

Ich hab deinen etwas mehr power
verliehen

Lokal ist doch erwünscht.
Nach dem Umschalten recht gute Zeit

 

[streithausen]

@streithausen
Wenn du den Sendcmd Patch zuerst anwendest klar, dann ist der Codestand nicht mehr gleich wie im 11704er SVN (der Sendcmd Patch greift auch in die reader-videoguard2.c ein) und mein Patch fährt gegen die Wand - ganz logisch

Ist mir klar, ich hatte nur zuerst Deinen Patch angewandt, daher die Verwirrung.
Ich weiß auch nicht wie "genau" patch die Zeilennummern nimmt, diese stimmen im patch nämlich nicht.

Sende mir Deine Datei mal bitte als ZIP.

LG