R
redneck eyeball
Copy & Paste van ergens anders, misschien snappen jullie er iets van ...
CU
Red
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...
Salu2
by MushoGraná
P.D.: Sorry to write this in English, but I do this why it's a technical text, I prefer it. My German is worster than my English....
CU
Red
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...
Salu2
by MushoGraná
P.D.: Sorry to write this in English, but I do this why it's a technical text, I prefer it. My German is worster than my English....
