Newsgroup: it.hobby.satellite-tv.digitale
Titolo: forse merita un occhiata...(lungo-esperti)

Mesdames, et sourtout Monsieurs, ą vous le plaisir de lire:
This is a little recopilation of a lot of ideas and experiencies of a lot
of people, like parisino, jopelines, acidbits, jetrothul, smakthefrogs,
myself, .... on the spanish boards about this new card's.
When anybody can help us, we're very gratefully.
First of all say that the ATR of the new cards is the same as the old
v6.0, except the version number (7.0). Here are the struct of a new v7.0
spanish card:
****escEntidad00=00 00 53 45 43 41 20 20 20 20 20 20 20 20 20 20 20 20 00
00 00 00 00 00 00 
; 00 00 SECA
PrimoescEntidad01=00 64 43 41 4E 41 4C 53 41 54 C9 4C 49 54 45 20 20 20 09
8F BF A6 19 9F 00 
; 00 64 CANALSATELITE
SecondoescEntidad02=00 66 43 41 4E 41 4C 53 41 54 C9 4C 49 54 45 32 20 20
09 8F BF A6 19 9F 00 
; 00 66 CANALSATELITE2
TerzoescEntidad03=00 67 43 41 4E 41 4C 53 41 54 C9 4C 49 54 45 33 20 20 09
8F BF A6 19 9F 00 
; CANALSATELITE3 
PBM SECA: ProviderBitMap=00 00 00 0F 00 10 DB 
PBM CANALSATELITE: ProviderPackageBitMap01=00 00 00 00 00 00 60 00 04 FF
FF FF 
PBM CANALSATELITE2: ProviderPackageBitMap02=00 00 00 00 00 00 00 00 04 FF
FF FF 
PBM CANALSATELITE3: ProviderPackageBitMap03=00 00 00 00 00 00 00 00 04 FF
FF FF 
00 01 F0 FF FF FF FF FF FF FF FF 15 00 80 
00 02 70 FF FF FF FF FF FF FF FF 36 00 C0 
03 00 07 03 00 47 00 64 04 1F 01 00 E0 
04 FB 48 28 7D 28 1A 76 E2 A4 BF A6 D0 
00 05 01 00 00 00 00 00 00 00 00 00 10 E0 
questro č lo startup...č fatto non seguendo l'ordine dei record ma
l'appartenza al provider... 
sempre sullo 00... 
00 78 FB 48 28 7D 28 1A 76 E2 A4 BF A6 D0 
00 F0 FB 48 28 7D 28 1A 76 E2 A4 BF A6 D0 
01 68 FB 48 28 7D 28 1A 76 E2 A4 BF A6 D0 
01 E0 FB 48 28 7D 28 1A 76 E2 A4 BF A6 D0 
passiamo allo 01: 
00 06 F0 FF FF FF FF FF FF FF FF 86 00 81 
00 07 50 FF FF FF FF FF FF FF FF 8B 00 C1 
00 08 F1 FF FF FF FF FF FF FF FF F5 00 81 
00 09 51 FF FF FF FF FF FF FF FF DE 00 C1 
00 0A F3 FF FF FF FF FF FF FF FF C1 00 81 
00 0B 53 FF FF FF FF FF FF FF FF 71 00 C1 
00 0C FE FF FF FF FF FF FF FF FF 3A 00 81 
passiamo allo 02: 
00 0D F0 FF FF FF FF FF FF FF FF F5 00 82 
00 0E 50 FF FF FF FF FF FF FF FF 84 00 C2 
00 0F F1 FF FF FF FF FF FF FF FF E6 00 82 
00 10 51 FF FF FF FF FF FF FF FF 36 00 C2 
00 11 F3 FF FF FF FF FF FF FF FF 48 00 82 
00 12 53 FF FF FF FF FF FF FF FF 82 00 C2 
00 13 FE FF FF FF FF FF FF FF FF C6 00 82 
03: 
00 14 F0 FF FF FF FF FF FF FF FF BF 00 83 
00 15 50 FF FF FF FF FF FF FF FF BB 00 C3 
00 16 F1 FF FF FF FF FF FF FF FF 2A 00 83 
00 17 51 FF FF FF FF FF FF FF FF 12 00 C3 
00 18 F3 FF FF FF FF FF FF FF FF 5C 00 83 
00 19 53 FF FF FF FF FF FF FF FF 4A 00 C3 
00 1A FE FF FF FF FF FF FF FF FF 22 00 83 
Ultimi dati: 
SerialNumStr=123.456.789 
StartUpRecord=01 00 00 00 00 00 00 00 00 00 10 04 
Version=00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
At this moment there are some spanish channels (i.e.: viajar, cartoon
networks) who sends the two INS 3C (the old and the new) if the card has
the ident 00 0C (old) and 0064 (new). For the other spanish providers (00
66 and 00 67) the still send nothing now. Here you have an example of log:
------------------ CAM -> CARD ----------------- 
CLAS: C1 
INS : 3C 
P1 : 01 
P2 : 0D 
LEN : 29 
------------------ CABECERA -------------------- 
C1 3C 01 0D 29 
-------------------DATOS------------------------ 
71 00 00 0C 07 D2 00 03 27 18 79 13 01 13 1C D1 4B 74 D4 97 E3 85 6E 7D EF
BD 7F 1E 9E 9A 68 CA 82 xx xx xx xx xx xx xx xx 90 00 
------------------------------------------------ 
------------------------------------------------ 
25/03/2002 21:55:11 
------------------------------------------------ 
---------------- CARD -> CAM ------------------- 
CLAS: C1 
INS : 3A 
P1 : 00 
P2 : 00 
LEN : 10 
------------------ CABECERA -------------------- 
C1 3A 00 00 10 
---------------------DATOS---------------------- 
14 10 54 81 40 40 51 1B 05 40 04 8D 04 05 10 65 90 00 
------------------------------------------------ 
------------------------------------------------ 
25/03/2002 21:55:12 
------------------------------------------------ 
------------------ CAM -> CARD ----------------- 
CLAS: C1 
INS : 3C 
P1 : 02 
P2 : BE 
LEN : 5C 
------------------ CABECERA -------------------- 
C1 3C 02 BE 5C 
-------------------DATOS------------------------ 
10 01 54 7C C2 EB 3A F9 D1 14 D4 C8 31 D8 EB 55 B0 DD 38 DC F0 F0 C9 2C 6B
0A 5D EE E6 1B 37 D1 C5 9E E1 1C 8B CF 90 24 8C 31 23 ED 2F 03 9D 91 6B 94
8B 1C EF A3 47 E9 0A B3 1D A7 50 68 22 F6 1F 76 7B AD 4B FCDD 66 7A 0C 21
67 21 BF 2B 32 BE F8 A5 B9 94 31 A7 59 AD EA AB 2F 90 02 
------------------------------------------------ 
You can see that the new 3C INS is completely distinct as the old. The
only same between two new INS 3C is the 10 01 at the beginning. So we
think that the encryption algo is distinct, and they are using
superencryption.
What can mean this nano 10 with value 01:
- It can be mean the provider who is directed by it's INS 3C (10 01, in
this case P1=01 -> 00 64). When they send INS 3C for the other two
providers, we can supose this. So for
a) Provider 00 64 ; 10 01
b) Provider 00 66 ; 10 02
c) Provider 00 67 ; 10 03
- It can be a flag for a hash-table for encrypt the INS
.....
At this moment, we doesn't know what will it mean.
What follow now is a very interesant study of parisino about the new INS
3C, why are completely distinct after nano 10 all the bytes of two
distinct new 3C.
Chapter 1: Analyzing the result of the first 8 bytes of the INS 3C
The prove is encrypt with some known simetric algos the input data with
the same key and prove if the result of doing this several times es always
the same.
The used data are:
DD DD DD DD DD DD DD DD = Input data
KK KK KK KK KK KK KK KK = Used key
RR RR RR RR RR RR RR RR = Result
The algos we used are: IDEA, BLOWFISH, CAST128, 3DES, RC5 and SAFER, all
in mode CFB.
The result are that the ouput of the encryption of the first 8 bytes
always are the same, if the input data and the key are the same, doing the
proccess several times.
So we think that the first 8 bytes ofter byte 2 of the INS 3C NO are the
same in all the INS 3C, posibely this 8 bytes are always different between
two INS 3C.
To prove this, we made the follow example. It's an invented 3C. It's
content before encrypt it with the key are:
10 01 04 D1 11 22 33 44 55 00 .......
- Nano D1 with the DW
- Nano 04 for open all the channels
- Nano 10 with the data 01
Of the 8 bytes after the "10 01" only will change the last 6. We will
encrypt it with a key and view the results, the algo we used are the algo
we knows all the life ( ). The key will be 11 22 33 44 55 66 77 88 
- 04 D1 11 22 33 44 55 00 + 11 22 33 44 55 66 77 88
Instruction after encrypting = 10 01 1F 58 D8 E2 C9 01 BF B7
- 04 D1 11 22 33 44 55 01 + 11 22 33 44 55 66 77 88
Instruction after encrypting = 10 01 4F 97 EC 44 CC 75 71 FF
- 04 D1 11 22 33 44 55 02 + 11 22 33 44 55 66 77 88
Instruction after encrypting = 10 01 19 CA 6B B2 E6 59 51 44
- 04 D1 11 22 33 44 55 0F + 11 22 33 44 55 66 77 88
Instruction after encrypting = 10 01 92 8D F4 0E 2D CE 50 71
If we can see we get similar instructions than they send us for the
provider 00 64, so we can "cuasi" say that at least one byte MUST be
change in the first 8 bytes to get that the 3C INS are always different.
This means that we can forgett the brute-force attack , why we haven't a
pattern to implement it. Also probably the algo is distinct, another
reason to not apply brute-force.
The design of the first 8 bytes can be have a lot of variants, here you
have any:
- 04 D1 11 22 33 44 55 66, nanos 04 and D1
- D1 11 22 33 44 55 66 77, nano D1
- 11 22 33 44 55 66 77 88, without nanos, the 8 first bytes are filling
bytes
- 7X 11 22 33 44 55 66 77, new nano 7X
Everybody can choose who you want, but my favourite's are 4, 3, 2,1 in
this order.
Chapter 2: Analyzing the result of the rest of bytes of the INS 3C
Now we can get yet an idea of what occurs in the first 8 bytes, but what
will occurs in the rest of bytes. Here we found also differences with we
know today. There are not groups of 8 bytes. Here an example:
We have as input data:
Data: 11 22 33 44 55 66 77 88 11 22 33 44 55 66 77 88
Key: 11 22 33 44 55 66 77 88
Result: EB 91 31 FE DB E7 61 A9 EB 91 31 FE DB E7 61 A9
We can see that the algo encrypt in groups of 8 bytes, it's the normal,
but it has a problem, the groups are independent.
In our case, all seems like this problem has ben deleted, because there
are not repetitions between various 0x3C. 
How does it work's this proccess in other known algos...We use another
parameter in the encryption proccess, the hash-buffer.
* The actors of the actual system are 3: Input data, Key and Algo
* The actors in the new system maybe are 4: Input data, Key, Hash-buffer
and Algo.
The proccess was (all is ficticious):
Input Data: 11 22 33 44 55 66 77 88 11 22 33 44 55 66 77 88
Key: 11 22 33 44 55 66 77 88
Hash: 01 01 01 01 01 01 01 01
Result1: 32 94 00 37 04 C9 FB DE
The first new thing was that the hash-buffer must be initialized by any
way. If you remember for this con be used our new nano 10 with his data
01. We supposed that 10 01 doesn't are encrypted.
This two bytes (10 01) DOESN'T BE encrypted why we need them for the
decrypted proccess. With the data 01 we initialize the hash buffer.
Without this two bytes without encryption, the proccess will give us the
status bytes 90 24 or 90 02, because we need the same hash-buffer in the
encrypt proccess than in the decrypt proccess.
Well, now we will encrypt the second block of 8 bytes. The first we must
do is building the has-buffer for this block. Here we make simply a XOR
with the key and the result of the encryption of the first block.
Hash-buffer of block1: 01 01 01 01 01 01 01 01
Encryption result of block1: 32 94 00 37 04 C9 FB DE
Result of the XOR: 33 95 01 36 05 C8 FA DF
So we have the next for the second block:
Input Data: 11 22 33 44 55 66 77 88
Key: 11 22 33 44 55 66 77 88
Hash-buffer: 33 95 01 36 05 C8 FA DF
Result1: 1F A8 78 0D 35 2C 85 6C
Final Encrypting Result of the two blocks are:
"32 94 00 37 04 C9 FB DE 88 1F A8 78 0D 35 2C 85 6C"
We can see that we're using the same key and the same data in the two
blocks, but the result is totally distinct, only adding a new actor, the
has-buffer.
With this simple test's, we can noticed that any more else have been
present in the encryption proccess, because with the present algos it's
impossible get the result's we can see with the new 0x3C. Maybe a
hash-buffer, but who knows it? 
Chapter 3: What now..... 
If there's anybody who still follows this threat , please think about
this....
Idea A: Can we say that the encryption proccess begins on the second byte
of the INS 0x3C?
Idea B: Can we say that the byte 0 and 1 with data 10 01, are the nano 10
and the data 0x01?
Idea C: Can we say that in the encryption of the first block are randomize
data who changes between the distinct INS 0x3C?
Idea D: Can we say that the encryption proccess use a hash-buffer who will
be initialized with any way by the data 01 of the nano 10?
My answers are:
-Idea A: It's possibely...
-Idea B: It's possibely...
-Idea C: It's possibely...
-Idea D: It's possibely... 
Of course, there are a lot of other ideas we can have. We only can say at
this moment that I only know that I know nothing... 
At least say, that I think that the only way to crack this new system are:
- There are a no-known bug to get keys.
- We can do a dump, and so study the system.
- Mr. Polanko & Cia tell us how the system work.
We can't use brute-force methods because I (we) think that the algo is
distinct and at the moment unknown.
Another interessant change we still haven't told about is the possibely
change of the firmware of our receiver's. 
Also there are more INS who have change, not only 0x3C, another INS who
change is the 0x16:
C1 16 00 00 07 ; 00 00 00 0F 00 10 DB 90 00
What will happen's tomorrow....
All was I related you, are extracted from the spanish boards and my
spanish friends. At this moment I haven't yet a new "Black Card". I'm
waiting for it to test all what I think. 
Guys, prepare the season's and the phoenix's.... 
Finally, viewing all I write you here, I think that we don't watch SECA2 a
long time ago...
Thank's to the reader who have come until here...
By Alex
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Mesdames, et sourtout Monsieurs, à vous le plaisir de lire:
[...]
Ora ci vorrebbe un esperto che dica a che percentuale di "hackeraggio"
corrisponde...

 Mesdames, et sourtout Monsieurs, ą vous le plaisir de lire:
Potresti indicarmi da dove hai preso questo articolo?
Vorrei seguire passo passo la discussione.
Ciao, Arao
