Aktuelles
Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Neue EMM ´s

  • Ersteller Ersteller Gelöschtes Mitglied 488570
  • Erstellt am Erstellt am
    Nobody is reading this thread right now.
den EK2 im entsprechenden EMM austauschen (gegen ein bekanntes Pärchen) geht ja leider auch nicht, weil der zum Entschlüsseln benötigte K3 ja für jede Box ebenfalls unterschiedlich ist - oder? :-)

Frage ist NICHT rhetorisch gemeint ... das ist auch einer der Punkte, die in der ETSI Spezifikation für mich als recht guten Englisch-Sprecher mehrdeutig formuliert sind. Hat jeder SOC aus einer Chipsatz-SERIE den gleichen SCK oder hat jeder einzelne Chip einen INDIVIDUELLEN SCK? - Antworten bitte begründen ... keine Spekulation :-)
 
Wenn der SCK zwischen den Decodern unterschiedlich wäre, könnte die payload des ins7423 auch für alle gleich sein, das Ergebnis wäre jedoch ein unterschiedlicher K1 von Karte zu Karte, Decoder zu Decoder, oder nicht?
 
Was gegen alle den gleichen SCK auf dem gleichen SOC spricht - der Chip kann Theoretisch bei mehreren Providern zum Einsatz kommen und wenn der Gehackt wird sind dann alle Geräte betroffen ...
Gegen einen Individuellen Key spricht eine Megagroße Datenbank es sei denn der wird generiert ...
Ich würde für einen Key für einen Provider sprechen - alle bei Sky Deutschland haben den gleichen
 
Ich denke ja noch immer das der nur Chip mäßig unterschiedlich ist.

Andersherum müsste er ja bei allen zertifizierten Geräten gleich sein, beim Generic Modus hat es auch geklappt.
 
Die 10 wird wohl die Anzahl der Runden sein für die Verschlüsselung. Zumindest klingt das Rund für AES 128
Ausgehend davon das AES mit einer Blockgröße von 128 Bit verwendet wird sind es in der Berechnung dann 10 Runden.
Die Rundenanzahl ist nicht im EMM da diese Zahl von der Blockgrösse vorgegeben wird und dadurch bereits fest steht. 128=10; 192=12; 256=14

Aus meinen eigenen Anwendungen ( Zutrittssysteme ) weiß ich dass auf den meisten verfügbaren Smartcards AES nach Rijndael verwendet wird weil das die beste Performance ergibt.
Weiter lässt AES nach Rijndael Varianten zu, es ist alles andere als einfach ohne Insiderwissen oder Dump der Karte den verwendeten oder abgeänderten Algo abzuleiten.

Für Interessierte ( Coder ) empfehle ich diese sehr gute die gibt auch einen Überblick was alles möglich ist bei AES nach Rijndael.
 
wie bringt uns das jetzt beim EMM weiter ?

18 90 16 <- Länge 18 = 24 Byte // Nano 90 Smartcard // Länge 16 = 22 Byte
44 01 <- Keyselect "V13"
1A 84 A6 95 5F 09 84 BB AE 01 AE BC BD 54 B5 F5
99 2B 73 38

Hier haben wir keinen Block der jetzt von der Länge her wirklich passen würde also muss hier wohl noch etwas zuviel des guten drinnen sein
Es ist einfach unmöglich das bei einem verschlüsselten EMM immer die gleiche länge rauskommt und mit "00" aufgefüllt werden muss
 
Zuletzt bearbeitet von einem Moderator:
Replacing the EK2 in the corresponding EMM (for a known pair) is unfortunately not possible either, because the K3 required for decryption is also different for each box - right? :)

The question is NOT meant rhetorically ... that is also one of the points that are ambiguously formulated in the ETSI specification for me as a very good English speaker. Does every SOC from a chipset SERIES have the same SCK or does every single chip have an INDIVIDUAL SCK? - Please give reasons for answers ... no speculation:)
forget ETSI and SCK
NDS use own root_key, that is stored in CPU OTP - K1
address of the key:
*** 00: 00: 06.074 BHSM: 036 - 0000001D
*** 00: 00: 06.075 BHSM: 040 - 00000027
*** 00: 00: 06.075 BHSM: 044 - 0000001D
*** 00: 00: 06.075 BHSM: 048 - 00000043

so, root_key + chip_id (chip_id + XOR80 = box_id) = unique_stb_key - K2

decrypting this with K2
*** 00: 00: 06.077 BHSM: 080 - 78695A4B
*** 00: 00: 06.077 BHSM: 084 - 3C2D1E0F
*** 00: 00: 06.077 BHSM: 088 - F0E1D2C3
*** 00: 00: 06.078 BHSM: 092 - B4A59687
= K3

dcrypting d37423 .. or 8030/8031 with K3 = K4

decrypting ECW with K4 = K5 (DCW)
 
Zuletzt bearbeitet:
Wenn dem so ist, würde das eine Berechnung enorm verkürzen.
Ich habe leider eine Solche Software nicht, die shiftrow könnte noch sichtbar sein, Galois-feld ist dann auch noch so ein Ding.
Aber es gibt bestimmt 2-3 Freerks die das hin bekommen können, nach und nach.

 
@panic
root_key + chip_id = unique_stb_key
root_key ist 16 byte lang, chip-id ist 4 byte lang

Was meint "+"? Dabei werden nur die letzten 4 byte verändert?
 
forget ETSI and SCK
NDS use own root_key, that is stored in CPU OTP - K1
address of the key:
*** 00: 00: 06.074 BHSM: 036 - 0000001D
*** 00: 00: 06.075 BHSM: 040 - 00000027
*** 00: 00: 06.075 BHSM: 044 - 0000001D
*** 00: 00: 06.075 BHSM: 048 - 00000043

so, root_key + chip_id (chip_id + XOR80 = box_id) = unique_stb_key - K2

decrypting this with K2
*** 00: 00: 06.077 BHSM: 080 - 78695A4B
*** 00: 00: 06.077 BHSM: 084 - 3C2D1E0F
*** 00: 00: 06.077 BHSM: 088 - F0E1D2C3
*** 00: 00: 06.078 BHSM: 092 - B4A59687
= K3

dcrypting d37423 .. or 8030/8031 with K3 = K4

decrypting ECW with K4 = K5 (DCW)

Root key isn't stored in OTP (physically). Rootkey will be calculated from OTP Key.
 
Zuletzt bearbeitet:
Aber an den otp dump kommste nocjt selbst mit tellnet zugriff den habe ich aber an das dump kommste nicht

Selbst wenn du zugriff hast mit telnet bekommsze den otp nicht gedumpt da das ein secret area ist und di nicjt rann kommst

Desweiteren Sind im OTP kein Playn Keys und Ohne die Berrechnungs Grundlage zum OTP_key kommen wir alle nicht weiter

wir müsten wissen NDS use own root_key, that is stored in CPU OTP und solang wir nicht die Berrechnungs Grundlage wissen kommt man da nicht ran

den es ist nur Hash

wie günthern schon schreibt

Root key isn't stored in OTP (physically). Rootkey will be calculated from OTP Key

wir brauchen den OTP Key bzw wo der Sitzt und wie man ran kommt

es gibt genügend Leute die zugrif haben auf Boxen doch ohne OTP Key gehts einfach nicht weiter.
 
Hm ich habe mich gefragt warum manche Teile vom EMM an die BoxID und manche an die Chip ID gehen ...

Wie genau kommt man den CWE Key ran , wie lang ist der und welchen Algo benutzt der ?
 
jepp du irrst dich ...
Chip ID + HEX 80 = BoxID

82 70 <- EMM
38 <- Länge 38 = 56 Bytes
C1 <- Nano C1 - Geht an die HW
D5 44 A7 18 <- BOXID
07 30 <- Nano 07 Länge 30 = 48
12 A8 10 <- Länge 12 = 18 Byte //Nano A8 Smartcard // Länge 10 = 16 Byte
42 73 35 10 <-<- 42 Hersteller Code HEX 42 = ASCII "B" Broadcom // CPU-ID : 7335 // 10 ist die CPU Rev. 10 Dez = Hex 0A also Rev. A
F0 72 AF 37 <- 1. bis 4. Byte von einem 16 Byte Hashkey
55 44 A7 18 <- Chip-ID ( Chip ID XOR 80 = BOXID )
00 00 00 00
25 1A <- Nano 25 Länge 1A = 26 Bytes
...
..

82 70 <- EMM
52 <- Länge 52 = 82 Bytes
C1 <- Nano C1 - Geht an die HW
55 44 A7 18 <- Chip-ID ( Chip ID XOR 80 = BOXID )
07 24 05 <- Längenangaben sein 07 = 7 Bytes bis zum ende der Boxid // 24 = 36 Bytes bis ende des HW Teils // 05 = 5 Bytes bis Ende BOXID
44 <- Modul / CAM
55 44 A7 18 <- Chip-ID ( Chip ID XOR 80 = BOXID )
25 1B <- Nano 25 Länge 1B = 27 Bytes
01 01 83 <- Nano 01 Länge 01 = 01 Bytes - 83
30 16 <- Nano 30 Länge 16 = 22 Bytes
00 02
25 3D 9D 82 B0 C6 4A AC CF A9 B1
...
...
 
Zuletzt bearbeitet von einem Moderator:
Zurück
Oben