Newsgroup: it.hobby.satellite-tv.digitale
Titolo: Seca 2 LOG

Forse a qualcuno interessa
------------------------------------------------------------------------
log seca2 card
Auteur: VL32
Datum: 04-08-02 22:23
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? :b
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... 8o
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...
------------------------------------------------------------------------


Vecchia....... e praticamente inutile.......
GMG