Neue EMM ´s

[J_Kl]

Wenn man sich den Ins7E aus dem ACL ansieht sieht man wo die keys herkommen.

(4D001660)
CI Plus Modul

Oder CI (Pro) - Modul

 

[Gelöschtes Mitglied 488570]

Bitte zurück zu den EMM´s ... das hatten wir schon im anderen Thread tausendmal ...

 

[007.4]

I've been looking at some of the Chip Manufacture IDs in a SkyUK EMM log.

42 73 35 10 ; Bs5 ; BCM 7335A (MIPS)
42 74 01 21 ; Bt.! ; BCM 7401 (MIPS)
6E 73 6B 20 ; nsk ; ???
6E 73 6B 21 ; nsk! ; ???

I suspect that latter two are SkyQ boxes with the STiH412 'Monaco' (ARM) chip.
Can anyone confirm?

 

[Gelöschtes Mitglied 488570]

6E 73 6B 21 ; nsk! ; ???

INS-7E - German Sky "Q" Box ist "6E 73 6B 21"

 

[Nirvi2]

Warum bruteforced man nicht aus EK2(K1) und K1 aus den alten 38C1 den K2? Gesetzt den Fall dass es beim K2 wieder 3DES mit zwei identischen Halbkeys ist wie beim K1 würde es ja funktionieren.

 

[caveman99]

Der K2 der V13 ist nicht DES-symmetrisch.

 

[Gelöschtes Mitglied 488570]

Edit: noch einmal drüber nachgedacht ... nein ist so nicht möglich

wenn K2 und K1 aus 2 x 8 Bytes bestehen sollen muss EK 1 auch aus 2 x 8 Bytes bestehen

 

[007.4]

I've been looking at the SlyUK EMMs that carry the information to assemble INS7E and the EK2.
They are very similar to the SkyDE 38C1 pair.

Spoiler

Parsing of the pair of EMMs used to create INS 7E and EK2. Taken from a random boxid of a SkyUK EMM log.

B4 7E 48 C2 ; boxid XOR 0x80000000
00 00 DA ; ?
07_30 ; tag/length (to end of EMM including checksum)
12 ; length
A8_10 ; tag/length
42 73 35 10 ; Chip ID (BCM7335A)
A5 DB 47 00 ; first 4 bytes of a hash or a nonce?
34 7E 48 C2 ; boxid ID For INS 7E
00 00 00 00
25_1A ; tag/length (to end of EMM excluding checksum)
01_01 ; tag/length
81 ; data? generic mode? for TAG 5501? However, unique mode 83 is in use.
30_15 ; tag/length
00 01 00 02 03 ; first five INS7E flag bytes
E1 D4 A1 B4 DC 8A 63 43 08 D0 45 83 70 xx xx 6E ; 1st 16 byte string EK2?
E3 ; Checksum of bytes 07+30+ ..to.. DD+6E

==
00 00 DA ; ?
07_30 ; tag/length
12 ; length
A8_10 ; tag/length
42 73 35 10 ; Chip ID (BCM7335A)
A5 DB 47 00 ; first 4 bytes of a hash or a nonce?
34 7E 48 C2 ; boxid ID For INS 7E
00 00 00 00 ; For INS 7E
25_1A ; tag/length
01_01 ; tag/length
81 ; data? generic mode? for TAG 5501? However, unique mode 83 is in use.
31_15 ; tag/length
00 02 [02] 02 03 ; Second five INS 7E flag bytes - encryption mode set ([02] indicates 3DES mode 2)
10 72 C7 49 31 8F 6E E0 E7 73 80 69 F9 xx xx 14 ; 2nd 16 byte string EK2?
EE ;Checksum of bytes 07+30+ ..to.. 17+14

Four questions:-

1. Which of these 16 byte strings is the EK2? 30_15 or 31_15?
Or are they manipulated togther( XORed? or 3DES crypted, with one as the data and the other the keys) to create the actual EK2?

I believe you have the same issue for SkyDE. Does anyone know the answer?

2. What are the four bytes after the Chip ID and their purpose??

3. 01_01 81 What does the "81" indicate?

Finally, to me it appears that oscam does not use the payload data in INS7423 anywhere. Is that correct?
If so, how can it work in unique mode? Surely EK1 comes from INS7423?

 

[kautz8953]

In mod81 EK2 (K1) come From the Receiver EMMs 38C1

In mod83 EK2 (K1) come from the ins7423

 

[007.4]

OK. Thank you.
Do you know how the two 16 bytes strings in the 38C1 EMMs are combined to create the EK2?

Also for unique mode, am I correct in thinking that currrently oscam does not use INS7423 for EK2 and therefore will need to be patched to use it
(either AES or 3DES depending upon the system - SkyDE - SkyUK respectively)?

 

[Miese.Ratte]

Do you know how the two 16 bytes strings in the 38C1 EMMs are combined to create the EK2?

They just don't!

 

[007.4]

Please clarify. The strings do not combine (in which case - which one is used) or is neither used for EK2 in generic mode?
Or no one (in public) knows how they are used at all?

 

[Miese.Ratte]

The two keys (strings in your lingo) are for different cards. They are very likely encrypted keys.

Because they are for different cards and do the same job, they can't be sufficient for an EK2.

 

[007.4]

Interesting. If you know that for sure then I'll accept it. Thank you.

However, all my testing indicates the INS7E creation EMMs (38C1 for SkyDE) have nothing to do with the card and are solely to do with the box, for the following reasons:-

1. These EMMs are addressed to the box not the card.
2. In UK there are currently THREE card types, 0960, 0961 and 0963. But there are only TWO 16 byte strings/keys/seeds. So where would the third card type get its data from?
3. I've logged the EMMs for two different card types in the same box. They are identical and give rise to exactly the same INS7E.
4. These 16 byte strings/keys/seeds follow the 30_15 and 31_15 nano_length tags. The first five bytes of these are flag bytes some of which denote the encryption method used (02 = TDES, 10 = AES etc) and which variation.

eg for SkyUK
30_15 00 01 00 02 03 .............
31_15 00 02 02 02 03 .............

eg for SkyDE
30_15 00 01 10 10 05 ............
31_15 00 02 10 10 05 ............

This suggests to me that, the following 16 bytes are the EK2 for the two different encryption types (TDES, AES etc) and variations, and the EK2 selected will be the one currently active.

 

[Miese.Ratte]

SkyDE has also three different cards.

The V13 gets fed with the first key and the V14/V15 use the second key. You can verify/see it while logging on the receiver during the decryption process when running in the global "pairing" mode aka mode 81.

These keys do also change sometimes. The K2 doesn't.

... and don't rely too much on the keyladder. NDS loves to modify those things here and there a little bit.