wenn man alles uniq keys nehmen würde inkl passenden ecw:dcw (die sich beispielsweise hier im board finden lassen)

[RuckZuck]

mal von der BoxID abgesehen, sind uns Modell ID und NonceID aus dem ins7E ja bereits bekannt...
4 Byte ModelID, 4 Byte NonceID, 4 Byte BoxID, ab 13. Byte 0000000000010202030002020203 oder aber nach V13/V14/(V15?) separiert (wenn @parasonic recht hat, kann es gerade nicht überprüfen) 0000000000010202030000000000 (V13) oder 0000000000000000000002020203(V14/(V15?))

M1 M2 M3 M4 N1 N2 N3 N4 B1 B2 B3 B4 00 00 00 00 00 01 02 02 03 00 02 02 02 03

 

[parasonic]

wenn @parasonic recht hat

Also ich kann es zumindest mit meiner V13 validieren.
Indem ich per "sendcmd"-Patch ein älteres ECM mehrmals sende, gleiche Karte, jeweils mit veschiedenen ins7e initialisiert..
Einmal mit Ins7E "normal", also = <ModelID><NonceId><CamId>0000000000010202030002020203
Einmal mit Ins7E = 0000000000000000<CamId>0000000000010202030000000000
Beides liefert in Mod81 vom GLEICHEN ECM das GLEICHE ECW!
Also fliessen in den K1_generic vom ins7e NUR diese beiden Stückchen mit ein, der Rest ist für Mod81 unrelevant.

Daraus lässt sich weiterhin schliessen, dass in den K1_unique (mod83) NUR der vordere Teil einfliesst, und der hintere unrelevant ist!
Denn im Mod83 funktioniert mit passendem K1_unique das hier (Bild hell):
<ModelID><NonceId><CamId>0000000000010202030002020203
genauso wie das hier:
<ModelID><NonceId><CamId>0000000000000000000000000000
Das kann zwar aktuell leider nur mit gebruteter v13 überprüft werden - aber ich wette ne Kiste Bier: das ist mit v14/15 ganz genauso.

Kann bitte mal jemand überprüfen/bestätigen, dass meine These oben (K1_generic) mit V14/15 auch so ist? Ich kann es nur mit v13 prüfen.
Der ins7E für Mod81 mit V14/15 wäre ja dann = 0000000000000000<BoxId>0000000000000000000002020203
Um es zu validieren, muss man allerdings mit sendcmd umgehen können, und noch ein passendes altes ECM (altes Oscam-Debuglog) haben, und ne V14/15 mit passenden Tiers.
Also ein ECM, welches noch von einem Mod81 Sender war, von der zur Karte passenden CAID, wo mod81 noch erlaubt war...

 

[TuzlaDVB]

Da geht noch mehr...

Hab' noch was für die beobachtende Zunft.

Wir wissen, dass ohne INS7E bei per F0 verrammelten Karten keine Freude aufkommt. Payload 00 10 00 ... igitt!

Deshalb gibt es eine kompliziert aussehende Anleitung, wie der Befehl zu basteln ist. Diese Anleitung will ich nicht anzweifeln. Die hat bestimmt der Season-Logger so verraten.

Die Anleitung spuckt für das Modul z. B. sowas aus:

4D001660ssssssssmmmmmmmm0000000000010202030002020203

ssssssss = S/N der Karte
mmmmmmmm = S/N des Moduls
00010202030002020203 entstammen den 38C1-EMMs

Wenn man diese Byteschlange richtig in der Config einträgt, spuckt Oscam CWEs aus. Zum Glück reicht das noch nicht. Soweit so bekannt.

Die große Frage war: Was von dieser INS7E wirkt sich tatsächlich auf das CWE aus? Immerhin sind die Karten- und Modul-Seriennummern bereits bekannt.

Eines vorweg: Die "boxid" aus der Config, beeinflusst das CWE. Witzigerweise wird eine "falsche" Boxid nicht abgelehnt (Payload 00 10 00 ...). Die Karte bemerkt das durchaus. Sie kommt mit einer anderen sw1/sw2 für INS4C zurück, wenn die Boxid nicht passt.

Trotzdem kommt bei veränderter Boxid nur ein anderes CWE herausgepurzelt. Die Karte wird aber nicht bockig. Warum auch immer! Vielleicht nutzt das ACL diesen Umstand aus. Ein Hack funktioniert so für alle Karten. Das würde nahe liegen.

Für das Experiment mit INS7E wurden ECMs trocken eingelegt und immer wieder auf die Karte gehetzt. Ändert sich das CWE, wird der veränderte Teil der INS7E berücksichtigt. Ändert sich nichts, ist es zumindest zzt. egal.

Heraus kam das Ding:

ffffffffffffffffffffffffffffffffffffffffffffff02ff03

Alle "ff" sind demnach sowas von Würstchen.

Wer hätte das gedacht? Ich nicht!

 

[parasonic]

Danke für den Link. Es ist also längst bestätigt worden
Also nur eine 02 und eine 03, und die CamId beeinflusst K1-generic mod81. Egal welcher Kartentyp. Interessant, thx.

 

[JoyriderLP]

Daraus lässt sich weiterhin schliessen, dass in den K1_unique (mod83) NUR der vordere Teil einfliesst, und der hintere unrelevant ist!
Denn im Mod83 funktioniert mit passendem K1_unique das hier (Bild hell):
<ModelID><NonceId><CamId>0000000000010202030002020203
genauso wie das hier:
<ModelID><NonceId><CamId>0000000000000000000000000000
Das kann zwar aktuell leider nur mit gebruteter v13 überprüft werden - aber ich wette ne Kiste Bier: das ist mit v14/15 ganz genauso.

Interessant wäre ob es auch mit

<ModelID><NonceId><CamId>1111111100000000000000000000

auch funktioniert weil es könnte ja auch sein das es ein Verschlüsselungskey ist der mit 00000000 nur auf 128bit aufgeblasen ist und deswegen die Nullen braucht und wenn man da andere Zahlen einfügt nicht mehr funktioniert!

So könnte es sein das man dies auch einfach über eine Key-Berechnung machen könnte und man dadurch nicht mehr über BruteForce gehen müsste
Hab leider keine V13 dadurch keinen Unique-Key

Aber wenn es mit den anderen Zahlen nicht funktionieren sollte könnte man ein wenig spielen mit verschieden arten von Verschlüsselungen und bei 2 oder 3 V13 keys vielleicht eine Übereinstimmung finden die man vielleicht auch auf die V14 ableiten könnte

 

[parasonic]

Interessant wäre ob es auch mit

<ModelID><NonceId><CamId>1111111100000000000000000000

auch funktioniert

Funktioniert nicht. Ändert man im ins7e nur ein einziges Bit von den ersten 128bit (also inkl. der 00000000 am Ende), dann wechselt die Karte sofort von mod83 nach mod81.
Also der ganze Modus (Algo) ändert sich dann.
Dazu braucht's keine v13, kann man auch mit ner v14 sehen ob ne 81er oder 83er Antwort kommt ;-)

Ne 83er Antwort und auch ein "korrektes" ECW gibt es z.B. mit dem hier:
<ModelID><NonceId><CamId>00000000FFFFFFFFFFFFFFFFFFFF

Ergo: die ersten 16byte/128bit sind für mod83 KOMPLETT relevant (fliessen in K1_unique ein).
Für Mod81 sind nur die boxid sowie die 02 und 03 relevant.
Oder nochmal anders ausgedrückt:

Spoiler

M1M2M3M4 N1N2N3N4 B1B2B3B4 00000000 00 01020203 00 02020203 # mod 81 Zutaten V13
M1M2M3M4 N1N2N3N4 B1B2B3B4 00000000 00 01020203 00 02020203 # mod 81 Zutaten V14/15
M1M2M3M4 N1N2N3N4 B1B2B3B4 00000000 00 01020203 00 02020203 # mod 83 Zutaten (alle Karten?)

Für mich eine recht interessante Erkenntnis - auch wenn andere die schon lange vor mir hatten :joycat:

P.S.: ändert man in mod81 etwas an den 02 bzw. 03 Werten, dann gibt es entweder gar kein CW mehr, oder ein komplett anderes / unbrauchbares mod81 ECW (sprich: da ändert sich dann der K1_generic!)

 

[parasonic]

<ModelID><NonceId><CamId>00000000 FFFFFFFFFFFFFFFFFFFF

Nachtrag: hab gerade bemerkt dass da nicht immer ein 00000000 hinter der CamId steht.
Nach einem Blick in emm Logs gibt es scheinbar noch solche ins7E, wo die ersten 16 byte mit 6E736B21 beginnen, und hinten auf 01989CD1 enden.
also z.B. so
6E736B21<NonceId><CamId>01989CD1 00011010040002101004

Auch der mod81 Teil hinten ist "anders" (nicht 02 02 03).
Das sind vermutlich diese komischen Kühe.
Kann das jemand bestätigen der ne Q box hat?

 

[seven95]

Ja, das ist bei meiner Kuhbox auch genau so.