Spanish Abertis DTT Sat @ Hispasat 30W - Chat & How to guides

U

uplevel

Registered
Messages
62
Colibri's experience in English(Google Translate from german):
Code: 
 Page 1
DVB TS full encryption cracked
DVB TS full encryption
cracked
For the first time, the DVB Transport Stream (TS)
Full encryption, not just parts like video and
Audio, but all PIDs (PAT, NIT, PMT, ...) encrypted
be cracked. A fully encrypted TS is over
tunneled a single data PID over a normal TS.
16.12.2011 (Version 1.00) current version http://colibri.net63.net or http://colibri-dvb.info
Colibri <[email protected]>
Some screenshots of the cracked programs
Page 2
DVB TS full encryption cracked
Page 2
content
Introduction ................................................. .................................................. .............................................. 2
Tunneled TS ................................................ .................................................. ...................................... 3
Normal untunneled TS ............................................... .................................................. .................. 19
Performance ................................................. .................................................. ....................................... 20
Recommendations ................................................. .................................................. .................................... 20
Literature ................................................. .................................................. .............................................. 20
DVB TS full encryption cracked
introduction
Programs encrypted with a fixed key the Control Word (CW) via satellite
were transferred, were already cracked some time ago. You make use of this,
that the key room with only 2 48 different options is too small to match with today
to be able to keep up with the gigantic computing power of graphics cards. The beginning (MPEG header) of
A decrypted video and audio packet is always known (byte sequence "00 00 01"). So can
Simply try with brute force every possible key. The beginning of such a
Packet, with the Payload Unit Start Indicator (PUSI) bit, in the always unencrypted TS header,
signaled. Thus, one can crack, depending on the graphics card, the CW within a few weeks.
Therefore, most vendors do not use Constant CW or Basic Interoperable Scrambling
System (BISS), but CA systems such as Nagravision, Cryptoworks, CONAX or Viaccess
where every few seconds a new CW is used to encrypt.
In contrast to pure encryption of video and audio comes for years, the TS
Full encryption for use. Here is a complete TS with its many programs and the
All administrative information PAT, NIT, SDT, EIT, PMT multiplexed into a single data PID. These
Data PID is then encrypted with BISS.
On the Internet I found the following:
For people in Spain who can not receive DVB-T, there is a Sat Receiver Teleview 5110
to be able to receive these programs directly via the Hispasat satellite (30 ° W). Such a
You can not just buy receivers, but an admitting dealer who works for Abertis Telecom
working, first has to make sure that really no DVB-T reception is possible. Only then will be
the bowl and the receiver set up by him.
The hackers' problem was that they no longer knew where in the Data PID that was
contains entire TS that start video or audio packets. Without this clue to the
Known-plaintext also fails the brute force.
Here is explained how I still managed to crack the system. A highlight is also the
First-time Common Scrambling Algorithm (CSA) Rainbow Table. Never before
Page 3
DVB TS full encryption cracked
Page 3
CWs were cracked with a CSA Rainbow Table. It takes a single time to create the table
also for a long time, but then I cracked several different CWs in minutes.
The next chapter will focus only on the Spanish DVB-T programs transmitted via the Hispasat satellite
(30 ° W). I'm interested in feedback if there are others
There are systems that transmit a whole TS tunneled through a single Data-PID.
The found CWs are not included here.
Tunneled TS
For the analysis I have such an encrypted PID, over which a whole TS is tunneled, times
recorded. The relevant frequencies and PIDs I have listed below in the document.
I then converted the binary file to HEX and all 188 bytes, which is the standard packet length,
insert a line transcript. In column mode, I then have the TS packet header (4
Bytes). Then I sorted the lines to better recognize patterns.
Byte 0
1
1
1
1
2
3
3
3
Bit 7..0 7
6
5
4..0 7..0 7..6
5..4
3..0
Sync
byte
47h
transport
error
indicator
payload
unit
begin
indicator
transport
priority
PID
transport
scrambling
control
adaptation
field
control
continuity
counter
Table 1: TS packet header
The result was surprising. Between most lines, as expected only once
In fact, there were always blocks with identical lines.
But how was that possible? MPEG is a very efficient format and even if there is a still image
are similar to a compressed file, no repetitive data too
expect.
Although there are not only audio and video but also other package types such as PAT, CAT, NIT, SDT or
PMTs that are more or less static. But these have in relation to the video packages
a much too small proportion in the TS and the many blocks with the same content actually not
cause.
So I took a step back and looked at not just an encrypted PID from the TS, but
the statistics of the entire TS.
There were PAT, CAT, NIT, TDT, EMMs, PMTs, some encrypted PIDs and ID 0x1FFF PIDs.
The PIDs with ID 0x1FFF are stuff packets that are transmitted by a variable bit rate, the
Eg caused by the MPEG video packets to the fixed bitrate a transponder has to
come.
The statistics also showed the number of packets per PID. That was very enlightening, because
the counters were identical for all encrypted PIDs. That means the keyed PIDs
Already had a fixed bitrate and they had to contain filling packages. That means that
many identical lines in the textfile were encrypted filler packages and that was crucial for
the hack. Because the content of the filling packages is usually static, sometimes an ascending one
Page 4
DVB TS full encryption cracked
page 4
Byte sequence but usually just nothing but zero bytes. With known Plaintext of the filling package, it is possible
create a rainbow table for this plaintext once. Then you can within
Minutes by hand of the encrypted filler block, which is encrypted by the many identical ones
Packets, the CW can be calculated with the Rainbow Table.
But why is not there just a single line content (the encrypted stuffing pack) the more often
occurs, but 47 lines contents which are present several times?
This is due to the multiplexing (tunneling) of a TS over a single PID. A TS package, with
Its 188 bytes, always consists of 4 header bytes + 184 bytes payload.
As payload of the encrypted PID, however, only 184 bytes are available around the TS
but not the necessary 188 bytes. The last 4 remaining bytes of the first packet
move to the beginning of the second packet and then come the remaining 8 bytes of the second packet
to the beginning of the third package.
OuterPkt1 header
InnerPkt1 header 4 bytes
InnerPkt1
Payload 180 bytes
OuterPkt2 header
InnerPkt1 Payload 4 Byte InnerPkt2 Header 4 Byte InnerPkt2
Payload 176 bytes
OuterPkt3 header
InnerPkt2 Payload 8 Byte InnerPkt3 Header 4 Byte InnerPkt3
Payload 172 bytes
OuterPkt4 header
InnerPkt3 Payload 12
byte
InnerPkt4 Header 4 Byte InnerPkt4
Payload 168 bytes
...
OuterPkt44 Header InnerPkt43 Payload 172
byte
InnerPkt44 Header 4
byte
InnerPkt44
Payload 8 bytes
OuterPkt45 Header InnerPkt44 Payload 176
byte
InnerPkt45 Header 4
byte
InnerPkt45
Payload 4 bytes
OuterPkt46 Header InnerPkt45 Payload 180
byte
InnerPkt46 header 4 bytes
OuterPkt47 Header InnerPkt46 Payload 184 Byte
To tunnel 46 packages you need 47 packages.
Decrypted, the 47 different filling packages look like this:
47 1F FF 10 00 00 00 00 <168 additional bytes> 00 00 00 00 00 00 00 00
00 00 00 00 47 1F FF 10 <168 additional bytes> 00 00 00 00 00 00 00 00
...
00 00 00 00 00 00 00 00 <168 additional bytes> 47 1F FF 10 00 00 00 00
00 00 00 00 00 00 00 00 <168 additional bytes> 00 00 00 00 47 1F FF 10
00 00 00 00 00 00 00 00 <168 additional bytes> 00 00 00 00 00 00 00 00
Based on which known Plaintext you build the Rainbow Table you can
choose. I took the last one with 184 zero bytes for my experiments. That has the
Advantage that one is independent of header changes. There are headers for the filling packages in
two variants once static 47 1F FF 10 and once with incrementing continuity counter 47 1F
FF 10, 47 1F FF 11, 47 1F FF 12, ..., 47 1F FF 1F. At the counted continuity counter arise
Page 5
DVB TS full encryption cracked
page 5
then more than the 47 variants, but then a variant is much more common. That is then
The ones with the encrypted 184 null bytes.
But which one, the approximately equal occurring encrypted packages, one accepts
a fixed continuity counter to calculate the CW with the Rainbow Table?
Of course you could try it with all 47 different packages, but what about the time
Calculate the CWs by this factor.
To solve this problem, we need to look at the adaptation field (AF).
In the TS header, there is a two-bit "adaptation field control" that indicates whether before the actual
Payload still an AF is present. The bits have the following meaning:
00 Reserved
01 No AF, only payload
10 AF only, no payload
11 AF and payload available
Let's take a look at a sample package with AF and Payload:
47 08 37 F2
13 12 5F 2D 60 2E 81 00 0B B5 80 96 B0 F8 52 00 00 00 00 00
AF 61 50 13 <156 additional bytes> 10 05 32 06
The first line is the TS header. In Hi-Nibble (F) of the last byte all bits are set (1111). The
first two bits belong to the transport scrambling control field and 11 means that the payload
is encrypted with the odd CW (10 would be Even-CW, 00 would be unencrypted and 01 is reserved).
The last two 11 bits mean AF and payload are present.
The second line shows the AF. The first byte (13h) gives the length of the remaining AF field
at. In total (1 length byte + 13h following) it is 14h = 20 bytes long.
The third line shows the encrypted payload. Taking one of the 184 available
bytes that are the length of the AF with its 20 bytes, then remain 164 bytes for the payload
left.
An AF is always transmitted unencrypted. It can eg timestamp (PCR) and provider
contain specific data. The content is not relevant to the hack. But that every now and then
is present and this provider always has a length of 20 bytes is crucial. It
thus causes the encrypted payload is no longer a multiple of 8.
Without AF, the payload always has 184 bytes consisting of 23 blocks of 8 bytes each.
With 20 bytes AF, the payload always has 164 bytes consisting of 20 blocks of 8 bytes each and one
Rest of 4 bytes.
But why does it help us if the payload length is not a multiple of 8 at our hack?
Page 6
DVB TS full encryption cracked
page 6
For this, we have to look more closely at and payload with the common scrambling algorithm
(CSA) is encrypted.
For encryption, the plaintext is divided from front to back into 8 blocks and the rest
(Plain Residue) first set aside.
The last 8 byte block is linked with the IV, which is always zero in the DVB-CSA, XOR and then
with the block cipher encrypted with the CW. The result is an intermediate block (IB). He will
linked with the penultimate plaintext XOR and then again with the block cipher with the CW
encrypted. The result is then the penultimate Intermediate Block. Do you have all the IBs?
then the cipher stream is initialized with the CW and with the contents of the first IB.
The first IB is also the first encrypted block. The remaining IBs will be with the
Output of the stream cipher XOR links and results in the remaining encrypted 8 bytes each
long blocks. Now the first time put aside Plain Residue is used. He will come with you
linked to the output of the stream cipher XOR and gives the encrypted remainder.
CB: cipher block
SB: Stream cipher block
CR: Crypt Residue
IB: Intermediate Block
CW: Control Word (Key)
PR: Plain Residue
PB: plain block
IV: Initialization Vector
Figure 1: CSA encryption
header
CB 0
CB 1
CB 2
CB 3
...
CB n-1
CR
IB 0
IB 1
IB 2
IB 3
...
IB n-1
PB 0
111101
PB 1
PB 2
...
PB n-2
PB n-1
PR
SB 1
SB 2
SB 3
SB n-1
SB 0
stream
cipher
init
block
cipher
encr.
CW
block
cipher
encr.
CW
block
cipher
encr.
CW
block
cipher
encr.
CW
block
cipher
encr.
CW
IV
CW
Page 7
DVB TS full encryption cracked
Page 7
When decrypting it works the other way around, as can be seen from the following picture:
The special feature of the encryption of our last 4 bytes of payload is that they even
not encrypted by the cipher block but only by the cipher stream.
But why does that help us to determine the one of the 47 variants that only consists of encrypted zeros
consists? The CW is not yet known to us and so we can not really know how
the 4, encrypted only with the stream cipher bytes, look decrypted.
However, if we knew that the decrypted bytes were 47 1F FF 10 then that would be
solved our problem, since this header with the PID 1FFF filling the package with its 184 zero bytes
initiates. So we could use the payload of the following package and the Rainbow Table the CW
to calculate.
Encrypt two packets with the CSA, with only a single one within the first 180 bytes
Bit is different, then the encrypted packets are totally different. Even the last 4
Bytes would be totally different because the first intermediate block used to initialize the
Stream ciphers is used, would be different and thus also the Keystream of the last 4
encrypted bytes.
It is different, however, if a change is not in the first 180 bytes, but only in the last
4 bytes takes place. Then the first 180 encrypted bytes are identical and only the remaining 4
Bytes are different. The plain text of the last 4 bytes differs in only one
Bit, then the two encrypted 4 bytes differ only in exactly this bit position
and the rest is identical.
Let's take a look at the last two of the 47 variants (without AF) from the top:
CB: cipher block
SB: Stream cipher block
CR: Crypt Residue
IB: Intermediate Block
CW: Control Word (Key)
PR: Plain Residue
PB: plain block
IV: Initialization Vector
Figure 2: CSA decryption
header
CB 0
CB 1
CB 2
CB 3
...
CB n-1
CR
IB 0
IB 1
IB 2
IB 3
...
IB n-1
PB 0
111101
PB 1
PB 2
...
PB n-2
PB n-1
PR
SB 1
SB 2
SB 3
SB n-1
SB 0
stream
cipher
init
block
cipher
decr.
CW
block
cipher
decr.
CW
block
cipher
decr.
CW
block
cipher
decr.
CW
block
cipher
decr.
CW
IV
CW
Page 8
DVB TS full encryption cracked
page 8
00 00 00 00 00 00 00 00 <168 additional bytes> 00 00 00 00 47 1F FF 10
00 00 00 00 00 00 00 00 <168 additional bytes> 00 00 00 00 00 00 00 00
Also in the packages with AF, there will be the following by 20 bytes shorter payload.
00 00 00 00 00 00 00 00 <148 additional bytes> 00 00 00 00 47 1F FF 10
00 00 00 00 00 00 00 00 <148 other bytes> 00 00 00 00 00 00 00 00
Also encrypted, these two payloads can be recognized. For this one filters out of the TS only the
Packages that have an AF then only writes the payload one line at a time and sorts the text file
subsequently. Now you will find encrypted blocks that are within the first 160 bytes
are identical, but differ within the last 4 bytes.
Since the first 160 bytes are identical, the stream stream of the stream ciphers is identical.
For the stream cipher:
Plain XOR Key = Crypt
Crypt XOR Key = Plain
Plain1 XOR Plain2 XOR Key1 XOR Key2 = Crypt1 XOR Crypt2
Since Key1 and Key2 are identical, you can abbreviate them:
Plain1 XOR Plain2 = Crypt1 XOR Crypt2
Now you use the values:
47 1F FF 10 XOR 00 00 00 00 = Crypt1 XOR Crypt2
47 1F FF 10 = Crypt1 XOR Crypt2
The following clip shows how four payloads end:
128 times: ... 66 8B 84 01 ED A4 49 C2 1A 51 7F 94 (= 00 00 00 00)
8 times: ... 66 8B 84 01 ED A4 49 C2 5D 4E 80 84 (= 47 1F FF 10)
2 times: ... 66 8B 84 01 ED A4 49 C2 5D 54 A2 84 (= 47 05 DD 10)
3 times: ... 66 8B 84 01 ED A4 49 C2 5D 54 A2 8B (= 47 05 DD 1F)
Except for the last 4 bytes, the front payload part is identical.
1A 51 7F 94 (Crypt1) XOR 5D 4E 80 84 (Crypt2) = 47 1F FF 10 (Plain1
XOR Plain2)
So either 1A 51 7F 94 corresponds to the plaintext 00 00 00 00 and 5D 4E 80 84 corresponds to 47 1F FF
10 or 1A 51 7F 94 corresponds to the plain text 47 1F FF 10 and 5D 4E 80 84 corresponds to the plain text
00 00 00 00.
Only if one accepts in this case for 1A 51 7F 94 the Plaintext 00 00 00 00 results for the
remaining two lines meaningful values ​​(starting with sync byte = 47h). If you only have two lines
has, one can assume that the line that occurs more frequently the Plaintext 00 00 00 00
Page 9
DVB TS full encryption cracked
Page 9
equivalent. If both lines are about the same number of times, you have to stop the cracking attempt twice
perform, but that's still better than dealing with all 47 variants.
You are now looking for the plaintext ... 47 1F FF 10 corresponding packet with the byte sequence ... 66 8B 84
01 ED A4 49 C2 5D 4E 80 84 in the original TS which was filtered to the encrypted PID, skips
then the next 4 header bytes and has a 184 byte long encrypted null byte sequence in front of him
with which you can calculate the CW from the Rainbow Table.
But there is not only the variant where the header starts exactly 4 bytes before the end of the payload:
00 00 00 00 00 00 00 00 <148 additional bytes> 00 00 00 00 47 1F FF 10
There are three more variants:
00 00 00 00 00 00 00 00 <148 additional bytes> 00 00 00 00 00 47 1F FF
00 00 00 00 00 00 00 00 <148 other bytes> 00 00 00 00 00 00 47 1F
00 00 00 00 00 00 00 00 <148 other bytes> 00 00 00 00 00 00 00 47
The multiplexer that is fed with the TS and then generates an encrypted PID,
Namely does not synchronize the headers so that they are aligned 4 bytes. That's for a flawless
Function not necessary. I once compared such a current with an older recording
and there were the sync bytes in different places. A simultaneous recording of one
other transponders showed that the position of the sync byte had not changed here.
Maybe the position of the sync byte changes every time the multiplexer boots or
short time the contact to the source, which feeds the multiplexer, breaks off.
I even had a record a year ago. At that time they also had 9 ° east
Posted. The used CWs are now still identical at 30 ° West in use. presumably
The CWs had never changed. However, not just a single CW comes for the
encrypted PIDs are used. In the following table is the CW No. for two different PIDs
same, then they were also encrypted with an identical CW:
Freq.
PID
(hex.)
Prg.
No.
CW
No.
TV, radio or data
provider \
program
TSID
Org.
NetID
11222H
SR: 30000ks
(08.12.2011)
7DA
3010
8th
7E4
3020
8th
7E5
3021
8th
7E6
3022
8th
7E7
2023
8th
7E8
3024
8th
11262H
SR: 30000ks
(08.12.2011)
848
3120
4
TV \ RTVE \ La 2
TV \ RTVE \ 24
TV \ RTVE \ Clan
041A
22D4
849
3121
4
TV \ RTVE \ La 1
R \ RNE \ Radio Nacional
R \ RNE \ Radio 5 Todo Noticias
0455
22D4
84A
3122
4
TV \ RTVE \ La 1
R \ RNE \ Radio Nacional
03F3
22D4
Page 10
DVB TS full encryption cracked
Page 10
R \ RNE \ Radio 5 Todo Noticias
84B
3123
4
TV \ RTVE \ La 1
R \ RNE \ Radio Nacional
R \ RNE \ Radio 5 Todo Noticias
03F5
22D4
84C
3124
4
TV \ RTVE \ La 1
R \ RNE \ Radio Nacional
R \ RNE \ Radio 5 Todo Noticias
03F6
22D4
84D
3125
10
84E
3126
4
TV \ RTVE \ La 1
R \ RNE \ Radio Nacional
R \ RNE \ Radio 5 Todo Noticias
044D
22D4
84F
3127
10
11302H
SR: 30000ks
(08.12.2011)
89D
3205
9
89E
3206
9
89F
3207
9
8A0
3208
9
8A2
3210
9
8AC
3220
9
8AD
3221
9
8AI
3222
9
8AF
3223
9
11653H
SR: 19680ks
(08.12.2011)
12D
1301
5
12F
1303
5
11677H
SR: 19684ks
(08.12.2011)
191
1401
5
192
1402
5
12523V
SR: 10400ks
(08.12.2011)
582
2410
7
12548V
SR: 29600ks
(08.12.2011)
2BD
1701
2
TV \ La Sexta \ laSexta2
TV \ La Sexta \ laSexta3
TV \ La Sexta \ laSexta HD
TV \ SOGECABLE \ CANAL + Dos
R \ SOGECABLE \ SER
R \ SOGECABLE \ 40 PRINCIPALES
R \ SOGECABLE \ CADENA DIAL
TV \ TELECINCO \ CUATRO
000E
22D4
2BE
1702
2
TV \ Tele5 \ Boing
TV \ Tele5 \ Telecinco HD
TV \ TELSON \ MTV
TV \ La 10 \ La 10
R \ La 10 \ ABC Punto Radio
000F
22D4
2BF
1703
2
TV \ ANTENA3 TELEVISION \ NITRO
TV \ ANTENA3 TELEVISION \ Antena3 HD
R \ ANTENA3 TELEVISION \ ONDA CERO
R \ ANTENA3 TELEVISION \ EUROPA FM
R \ ANTENA3 TELEVISION \ ONDA
0010
22D4
Page 11
DVB TS full encryption cracked
Page 11
MELODIA
TV \ MARCA TV \ MARCA TV
TV \ VEOTV \ 13 TV
TV \ VEOTV \ MundoInteractivo
R \ COPE \ COPE
R \ Radio Maria \ Radio Maria
12631V
SR: 30000ks
(08.12.2011)
1F41
1001
11
1F42
1002
3
TV \ RTVE \ TVE-HD Pruebas
TV \ RTVE \ TDP
R \ RNE \ Radio Clasica HQ
R \ RNE \ Radio 3
Data \ RTVE \ Canal Ingenieria
9C40
22D4
1F43
1003
12
TV \ La Sexta \ laSexta
TV \ La Sexta \ GOL TELEVISION
TV \ La Sexta \ laSexta3
TV \ TELECINCO \ CUATRO
TV \ TELECINCO \ DIVINITY
TV \ TELECINCO \ LA TIENDA EN CASA
0002
22D4
12671V
SR: 30000ks
(08.12.2011)
1F44
1004
13
1F45
1005
14
1F46
1006
12
TV \ RTVE \ La 1
TV \ RTVE \ La 2
TV \ RTVE \ 24
TV \ RTVE \ Clan
R \ RNE \ Radio Nacional
R \ RNE \ Radio 5 Todo Noticias
03F0
22D4
Table 2: Transmission table
Normally one would need for the 4 possible sync byte positions also 4 rainbow tables, the
based on 4 different plaintexts to crack all PIDs. The sync byte positions
the different PIDs are mixed.
But because there are several PIDs that have different sync byte positions, with the same CW
Encrypted, it suffices that a single sync byte position with its own Rainbow Table
matches. If you have calculated the CW, you can with the CW and the other PIDs
decrypt. Is not the own sync byte position and you do not want another Rainbow
Create tables, then you can check it out in a few weeks again if the sync byte
Changed positions.
For this hack, I just got a full rainbow table for a single sync byte
Positions that can crack the 184 null bytes are created. That is why the above table also has
some gaps. If no program name is specified, the CW is not yet known.
If in the package with the AF the last 4 encrypted bytes, the value 00 00 00 00
represent, was identical for different PIDs, then I have the same CW in the table
No awarded. Thus one knows also with the still not found CWs how many there are still.
Page 12
DVB TS full encryption cracked
page 12
A bad habit that I noticed in recent records is that the filling packages now at
some transponders contain dynamic additional data and thus unfortunately not more for Rainbow
Tables are suitable.
The first 8 bytes of the filling package then contain additional data, the rest are zero.
The first byte is apparently always 01h if additional data is available.
The second byte is 00h.
The third and the fourth byte is a two-byte counter which increments by one when the multiplexer
accepts a filling packet or a payload package. So you can easily tell if it's one
There was packet loss on the link and even if it was just a packet or 20.
The fifth and sixth bytes are static.
The seventh and eighth byte is the TSID.
A security measure is not the whole thing. It is only partially used.
Also, the 16 bit counter is far too small for a security measure. That would be all 65536 packages
The filling package is identical again and can thus be used to create a rainbow table.
This gave me the idea, as Plaintext to create the Rainbow Table is not the content of
To use filling packages. Another positive side effect is that you can not sync yourself anymore
Byte position, but only one and not four rainbow tables needed.
But which static data is still available in the TS?
There are tables such as PAT, CAT, NIT, TDT or PMT which are broadcast regularly. The
Tables often do not use the whole payload. The rest of the payload is always using 0xFF bytes
refilled. For example, the Time and Date Table (TDT) only contains the date and time. That only makes one
few bytes out. Even with typically large packages such as a Network Information Table (NIT)
it can extend over several packages, it is nevertheless possible that they two complete packages
needed and only a few bytes from the third package. Then in the third package are also a lot of 0xFF
Bytes. Even in the Video PID there are always packages that have only one AF but no payload.
AF only contains the Program Clock Reference (PCR), the rest is 0xFF bytes
refilled.
As Plaintext now simply 184 * FFh (instead of 184 * 00h) to take but will not be successful
to lead. We will not find so many FFh bytes at a time, as they are only used for refilling
become. The trick with the encrypted PID is not to use the packets which are just a payload
of 184 bytes, but only the packages with AF and payload. Because the AF at this provider
always has 20 bytes, the payload has only 164 bytes. As we are creating the Rainbow Table
use only the block cipher and not the stream cipher, fall even the last 4 bytes
path. So we only need 160 bytes with the value FFh and that's no problem
more.
But how do you recognize encrypted FFh bytes?
Page 13
DVB TS full encryption cracked
Page 13
Let's just filter from the TS only the packages which in addition to the payload also an AF (with 20 bytes)
to have. The payload with the 164 bytes is written in a text file. Then we sort those
Text file so that the packages with the same beginning are together. We are interested
only for the lines where the first 160 bytes are identical. Here is an example from the
Practice:
17 times ... 91 B8 04 49 71 8D 04 51 F4 7D 87 8E (= ... 00 00 00 00 47 1F)
18 times ... 91 B8 04 49 71 8D 04 51 F4 7D 87 91 (= ... 00 00 00 00 47 00)
4 times ... 91 B8 04 49 71 8D 04 51 F4 7D 87 92 (= ... 00 00 00 00 47 03)
7 times ... 91 B8 04 49 71 8D 04 51 F4 7D 87 94 (= ... 00 00 00 00 47 05)
201 times ... 91 B8 04 49 71 8D 04 51 F4 7D C0 91 (= ... 00 00 00 00 00 00)
13 times ... 27 AD F5 03 5B 04 F1 23 2C B5 37 09 (= ... FF FF FF FF FF FF)
2 times ... 27 AD F5 03 5B 04 F1 23 2C B5 8F F6 (= ... FF FF FF FF 47 00)
Two different blocks were found that occur more often and within the first 160
Bytes are identical.
We now look at the first block of the first block, the last 4 bytes, which only with the stream cipher
have been encrypted.
In each case the first (F4h) of the four last bytes is identical and therefore we skip it.
In each case the second byte (7Dh) is also identical and we skip it again.
The third byte is öffters 87h, but only once C0h. One of these values ​​should decrypt the sync
Be byte 47h.
But what value does the other Plainbyte have?
We already know the procedure from above.
Crypt1 XOR Crypt2 = Plain1 XOR Plain2
But also:
Crypt1 XOR Crypt2 XOR Plain1 = Plain2
87h XOR C0h XOR 47h = 00h
The C0h corresponds to decrypted apparently 00h, because it occurs 201 times more often.
So the first block is apparently not the block you're looking for with its zeros, because we're looking for it
after FFh bytes.
Let's turn to the second remaining block.
Again, the first difference is in the third of the last four bytes.
37h XOR 8F XOR 47h = FFh
This looks better now. The last 4 bytes will need to calculate the CW with the Rainbow
Table not. The first 160 bytes (... 04 F1 23) are enough. They correspond to 160 times the byte FFh.
Page 14
DVB TS full encryption cracked
Page 14
Due to time constraints, I have not generated a full rainbow table with 160 times FFh, but instead
just enough that I could calculate one of the as yet unknown CW. I just went around here
Principle, whether this also works in practice.
So far, we have seen what plaintexts are used to create your rainbow table
and what advantages and disadvantages the various plain texts have. Also know
as we come to the appropriate ciphertext to calculate the CW with the Rainbow Table
can.
But how do we create the Rainbow Table and how exactly do we use it to calculate the CW later?
First you should read [1] to understand the principle of the Rainbow Tables.
Although the CW has a length of 8 bytes and thus 2 64 different keys would be possible, but
the number of different keys is always artificially limited to 2 48 for all receivers .
Presumably, the 2 16 have kept in reserve in case of cracking of the system (eg
via Rainbow Tables) it immediately by utilizing the full 2 64 keys via a firmware update
to make sure again. Hopefully there will be enough time left to become a successor to the CSA
Algo which supports a higher key length (eg AES). It then has to be natural
new receivers are produced which support both variants (eg CSA and AES). If the
End customers then have the new receivers that could be abrupt on new encryption
before the 2 64 keys can be cracked in practice with Rainbow Tables.
Within the Rainbow Table you can currently work with 6 bytes for the key.
This key can then be extended from 6 to 8 bytes for CSA encryption as follows:
Cw8 [0] = Cw6 [0];
Cw8 [1] = Cw6 [1];
Cw8 [2] = Cw6 [2];
Cw8 [3] = Cw6 [0] + Cw6 [1] + Cw6 [2];
Cw8 [4] = Cw6 [3];
Cw8 [5] = Cw6 [4];
Cw8 [6] = Cw6 [5];
Cw8 [7] = Cw6 [3] + Cw6 [4] + Cw6 [4];
The size of the rainbow table can indeed influence the chain length.
The bigger the rainbow table, the faster a CW can be found later, but the more
more disk space is then needed.
I chose chain length for 10000h (2 16 ). The Rainbow Table only has to
the remaining 2 48-16 = 2 32 pairs of start and end value can still contain the CW
calculate relatively quickly.
The start value and the end value represent the CW, so each need 6 bytes within the
Rainbow table.
The size of the Rainbow Table is calculated as follows:
(6 + 6) * 2 32 = 48 GB
Page 15
DVB TS full encryption cracked
Page 15
The frame parameters are plugged in and you can start generating.
You choose a 6 byte CW as start value. From the first to the last starting value is always at one
incremented. If one chooses 0 as the starting value then the following range results:
00 00 00 00 00 00 ... 00 00 FF FF FF FF
This starting value is very unfavorable. Someone else from the community could be at 0
Start and the resulting 48GB would be identical. So a rainbow table covers
not 100% off, but the CSA as I think about 66%. During the chaining of each
10000h elements must always have the entropy of 2 64 (Crypt Block) to 2 48 (CW length)
be reduced. As a result, inevitably merge a lot of chains and give the same
End value. The goal is to have several different rainbow tables with different
Starting values ​​to be as close as possible to the 100% coverage. The first two
Bytes of the start value should be absolutely random, the remaining 4 bytes should have 0. For example:
C3 E9 00 00 00 00 ... C3 E9 FF FF FF FF
To calculate the final value from the starting value, you can do something like this:
for (RoundNr = 0; RoundNr <0x10000; RoundNr ++)
{
// encrypt
// input 8 bytes: Cw
// output 8 bytes: data
// inside the fctn: 184 or 160 bytes fixed plaintext
BlockCipherEncryptPlain (Cw, data);
// Reduction of data from 8 bytes to 6 bytes
// in which data [6] and data [7] are not used
// XOR-linking the RoundNo to the data
data [2] ^ = ((RoundNo **** 24) & 0xFF);
data [3] ^ = ((RoundNo **** 16) & 0xFF);
data [4] ^ = ((RoundNo **** 8) & 0xFF);
data [5] ^ = (RoundNr & 0xFF);
// Convert 6 bytes of data to 8 bytes CW
Cw [0] = data [0];
Cw [1] = data [1];
Cw [2] = data [2];
Cw [3] = data [0] + data [1] + data [2];
Cw [4] = data [3];
Cw [5] = data [4];
Cw [6] = data [5];
Cw [7] = data [3] + data [4] + data [5];
}
memcpy (final value, data, 6); // accept the first 6 bytes as the final value
Page 16
DVB TS full encryption cracked
Page 16
Here are some intermediate results
184 * 00h. Only the start and end value will be saved later. You can do it your own
Check implementation (but then change the start value!):
Cw6: 00 00 00 00 00 00
<= Start value
Crypt: BF 8A 91 00 77 6F 7D A5
XOR RoundNr: 0h
Cw6: BF 8A 91 00 77 6F
Crypt: 1A 83 E3 00 58 84 B0 C6
XOR RoundNr: 1h
Cw6: 1A 83 E3 00 58 85
Crypt: 76 93 55 40 35 8B 2E AE
XOR RoundNr: 2h
Cw6: 76 93 55 40 35 89
Crypt: FC 8D 87 4C CF 75 9D 62
XOR RoundNr: 3h
Cw6: FC 8D 87 4C CF 76
...
Cw6: 86 48 D2 8E 21 BF
Crypt: DA C4 02 09 51 9E C0 DB
XOR RoundNr: FFFCh
Cw6: DA C4 02 09 AE 62
Crypt: 54 05 79 9D 95 F0 0E A9
XOR RoundNr: FFFDh
Cw6: 54 05 79 9D 6A 0D
Crypt: AA 28 CA FD B7 5D 50 9E
XOR RoundNr: FFFEh
Cw6: AA 28 CA FD 48 A3
Crypt: 3A 39 2A E6 42 61 D9 4B
XOR RoundNr: FFFFh
Cw6: 3A 39 2A E6 BD 9E
<= Final value
The Beginning of the 48GB Rainbow Table for the Plaintext 184 * 00h. You can see that
6-byte start value and then the 6-byte end value.
00 00 00 00 00 00 3A 39 2A E6 BD 9E
00 00 00 00 00 01 E4 63 9C 23 DE 8C
00 00 00 00 00 02 BE 2F FF 98 7F 10
00 00 00 00 00 03 29 E3 9D 3B AD 99
00 00 00 00 00 04 A2 AA AA D0 C6 C6
00 00 00 00 00 05 A6 EE 31 57 49 E0
00 00 00 00 00 06 55 93 42 66 48 DC
00 00 00 00 00 07 67 59 5C D2 79 82
00 00 00 00 00 08 B1 78 C9 8F 49 30
00 00 00 00 00 09 47 A8 37 2B 13 0B
...
00 00 FF FF FF F6 7F 3E EA 6E FE D7
00 00 FF FF FF F7 69 B7 A1 4A 96 D4
00 00 FF FF FF F8 A3 AA 14 3F 3C EB
00 00 FF FF FF F9 4B 91 99 AA C8 02
00 00 FF FF FF FA D4 24 2F C6 57 A1
00 00 FF FF FF FB 6A 06 C0 6A C1 FA
00 00 FF FF FF FC 6D B4 5E 46 A2 87
00 00 FF FF FF FD 3C 24 CD 0B 73 09
Page 17
DVB TS full encryption cracked
Page 17
00 00 FF FF FF FE 1B 15 4B 20 BE 61
00 00 FF FF FF FF 57 10 46 C9 5D 70
After creating the Rainbow Table, which is sorted by ascending starting values, you have to
now resort to ascending final values
because when calculating a CW with the Rainbow Table, it searches for specific end values. has
If you find them the corresponding value is read out for further calculation:
00 00 11 6F 08 DB 00 00 00 02 47 07
00 00 86 27 08 E3 00 00 00 04 A6 18
00 00 6F 17 6A 22 00 00 00 04 A6 18
00 00 C5 69 2A 71 00 00 00 05 41 D4
00 00 99 53 B3 A0 00 00 00 05 41 D4
00 00 17 53 49 1A 00 00 00 05 41 D4
00 00 50 B1 62 86 00 00 00 06 73 BB
00 00 E4 EA 92 74 00 00 00 09 1F F2
00 00 A1 90 32 B8 00 00 00 09 1F F2
00 00 CB E4 99 8D 00 00 00 0F 06 A9
...
00 00 FD E3 71 39 FF FF FF F5 71 22
00 00 42 46 50 39 FF FF FF F6 7D 46
00 00 73 E6 2D 18 FF FF FF F6 CB 2F
00 00 94 E8 5C B5 FF FF FF F7 26 85
00 00 DF B4 C9 CA FF FF FF FA 69 33
00 00 36 9C 8D 69 FF FF FF FA BB 30
00 00 1E 4D FD C8 FF FF FF FA BB 30
00 00 50 F0 61 D0 FF FF FF FB 0E 88
00 00 F0 90 82 23 FF FF FF FB 89 A3
00 00 10 FD 97 EA FF FF FF FF 5B D4
One can now see the above merge, which leads to the same final values.
We now have our Rainbow Table, but how do you determine the CW with it and a ciphertext?
Let's clarify this with the help of our example above.
We found an encrypted package that corresponds to the plaintext 184 * 00h. So
Payload AA 28 CA FD B7 5D 50 9E to the CW
to find out the rainbow table.
We shorten AA 28 CA FD B7 5D 50 9E to 6 bytes and perform on XOR operation with the last one
RoundNr FFFFh through. We compare the 6 bytes with all final values ​​of the Rainbow Table. There are
no agreement.
We shorten AA 28 CA FD B7 5D 50 9E to 6 bytes and perform at XOR operation with the
penultimate RoundNr FFFEh through. The Cw6: AA 28 CA FD 48 A3 we convert to Cw8 and
we encrypt our plaintext 184 * 00h again. The result is the ciphertext 3A 39 2A E6 42 61
D9 4B. Then XOR with the RoundNr FFFFh. We compare the 6 bytes 3A 39 2A E6 BD 9E with
all final values ​​of the Rainbow Table. Now there is a match. If this final value
Several times in the Rainbow Table, you have the following for each associated start value
to repeat. We get the starting value 00 00 00 00 00 00 from the
Rainbow table. Then we will again as we did when creating the Rainbow Table
have done a chain the beginning with our starting value 00 00 00 00 00 00. In doing so
Page 18
DVB TS full encryption cracked
Page 18
After each encryption we check the result with our cipher text AA 28 CA FD B7 5D 50
matches. If yes, then we take the Cw6 54 05 79 9D 6A 0D this ciphertext
Has resulted in converting it to a Cw8 and done. Otherwise, the whole thing will repeat until we
arrived at round 0.
Cw6: 00 00 00 00 00 00
<= Start value
Crypt: BF 8A 91 00 77 6F 7D A5
XOR RoundNr: 0h
Cw6: BF 8A 91 00 77 6F
Crypt: 1A 83 E3 00 58 84 B0 C6
XOR RoundNr: 1h
...
Crypt: 54 05 79 9D 95 F0 0E A9
XOR RoundNr: FFFDh
Cw6: 54 05 79 9D 6A 0D
Crypt: AA 28 CA FD B7 5D 50 9E
XOR RoundNr: FFFEh
Cw6: AA 28 CA FD 48 A3
Crypt: 3A 39 2A E6 42 61 D9 4B
XOR RoundNr: FFFFh
Cw6: 3A 39 2A E6 BD 9E
<= Final value
Page 19
DVB TS full encryption cracked
Page 19
Normal untunneled TS
So far, it just about tunneled TS, but what about conventional untunneled TS with the
Calculating CWs with Rainbow Tables?
Since only video and audio are encrypted here, many well-known plain texts are omitted here. I have
That's why I watch the video PID from an unencrypted station into the HEX editor. The
The interesting thing was that I saw several differently sized blocks of zeroes. They were
always at the end of an MPEG package. But not every MPEG packet has zeros in the end. If the
the last remainder of an MPEG packet does not fit into a TS packet with 184 byte payload, then becomes in the
Last TS package so housed at AF. The AF is so big that the end of MPEG packet exactly
matches the end of the payload from the TS packet. The following TS package then has the payload
Unit Start Indicator (PUSI) bit set and contains the beginning of the
next MPEG package.
But how do you know if a particular encrypted video PID
even such practical zeros were encrypted with?
One compares the payload of the packages which have AF. If two
Identical occurrences, then it is most likely encrypted
Zeros.
To test this I have a Rainbow Table
which is based on the plaintext of 8 zero bytes.
If a payload only has 0-7 bytes, then they will be used as a
encrypted marked Paktet always transmitted in plain text. The CSA
Algo can only encrypt from 8 bytes, with less bytes always
passed through transparent.
A rainbow table based on 8 zero bytes can crack the payloads
are between 8 and 15 bytes and where the first 8 bytes
are encrypted zeros. The remaining up to 7 bytes only go through
the stream cipher and not by the block chipher. Their value is
thus irrelevant.
I took a few channels with Mediaguard 3,
Nagravision 3, Viaccess 3 and VideoGuard are encrypted. So it wants to be
no fixed CW as used in BISS, but about every 10
Seconds changing. Of course I could with the fragment of mine
Rainbow Table only one of the CWs, so only one
Decrypt the cryptoperiod. For a few screenshots (see right) has
but enough.
Figure 3: 30W 11731H
PID 1651h "FX Portugal"
Figure 4: 30W 11731H
PID 1671h "Fox HD Spain &
Portugal"
Figure 5: 13E 10796V PID
AAh "Orange sport Polska"
Figure 6: 13E 12731H
PID A7h "Int101_1"
Figure 7: 13E 12731H
PID A8h "Int101_2"
Page 20
DVB TS full encryption cracked
Page 20
performance
With my 12% Overclocked NVIDIA GeForce GTX 470 (GV-N470SO-13I) I come to the following
Performance:
Plaintext length
CWs per second create time
Avg. time to
Determine a CW
184 bytes
30 million
109 days
170 sec.
160 bytes
33 million
99 days
8 bytes
71 million
45 days
The CWs per second are measured, the production time extrapolated. I have only one
Rainbow Table with the 184 bytes completely generated and even there I have the calculator not
run through a piece.
Generating the round keys for the blockcipher consumes a lot of time, but only once per CW
be necessary. Encrypting per 8-byte block is much faster and less significant. That's it
the speed in the table above is not uniform in relation to the 8 byte blocks.
Possibly. a CUDA [2] professional can get even more out of the map.
recommendations
Clearly, the key length of only 48 bits used in practice is too small to counter
To be able to withstand rainbow tables. A firmware update, which is full of the CSA chip
support 64 bits is necessary to protect against rainbow table attacks
be. Since this protection does not last forever, must immediately with the development of a CSA successor
to be started. For example, the already finished AES Algo can be used.
literature
[1] Karsten Nohl, Kunterbuntes Schlüsselraten, http://www.heise.de/security/artikel/Von-
Woerterbuechern-and-rainbows-270088.html
[2] http://www.nvidia.de/object/what_is_cuda_new_de.html
 
U

uplevel

Registered
Messages
62
Come on first step.

1.Powerful VGA Card, like 1080Ti/1080
2.CSA-Rainbow-Table-Tool_V1.19f
3.Create A0hx00h_table
4.When table is ready(after few months)test with 160 payload size, use right Crypt8 and find correct CW.

Anybody with another opinion?
 
Last edited:
Ramboide

Ramboide

Registered
Messages
202
plevel said:
Come on first step.

1.Powerful VGA Card, like 1080Ti/1080
2.CSA-Rainbow-Table-Tool_V1.19f
3.Create A0hx00h_table
4.When table is ready(after few months)test with 160 payload size, use right Crypt8 and find correct CW.

Anybody with another opinion?
Click to expand...

It seems to be easier to win a lottery, which is necessary to buy everything what is needed.

I have seen the Colibri's page and it seems to be necessary to download Terabytes of tables, a very large hard disk to fit them, and also a supercomputer and a super graphic card.

I've read that V2 requieres less resources.
 
Last edited:
Ramboide

Ramboide

Registered
Messages
202
plevel said:
Come on first step.

1.Powerful VGA Card, like 1080Ti/1080
2.CSA-Rainbow-Table-Tool_V1.19f
3.Create A0hx00h_table
4.When table is ready(after few months)test with 160 payload size, use right Crypt8 and find correct CW.

Anybody with another opinion?
Click to expand...

In my humble opinion, the best thing we can do is stop wasting time, effort and money with this shit. There are many better things to do.
 
EnoSat

EnoSat

Senior Member
Messages
1,978
but on low bitrate streams only identifications pids
without real audio-video pids

30_W_11677_H_stream_PID_431.png
 
B

bogyman

Donating Member
Messages
190
@enosat @all don't waste your time bcz dvlajkovic milan58 and enosat have the correct parameters + keys

I have a friend with FPGA biss bf
He can find the keys easily
I need correct PIDs
Sid vpid apid pmtpid pcr
12631 V - SR 30000 - 3/4 - S2/8PSK
8002

12549 V - SR 29600 - 3/4 - S2/8PSK
701
 
B

bogyman

Donating Member
Messages
190
I'll wait to my tbs5925 to arrive then do it by myself &#55357;&#56843;, FPGA bf is much faster than a0h table

No one will share the parameters even in private
 
R

rom20051

Registered
Messages
73
"F 03E91FFF 01 2E4E9511A3155C14 ;ABERTIS 8001 (30W) RGE Madrid
La1 Madrid, La1 Madrid HD, La2 Madrid, 24h Madrid and Clan Madrid"

La2 HD Madrid does not exist? If yes, what is his SID?
 
R

rom20051

Registered
Messages
73
La 1 ... 530
LA 1 HD ...534
La2 ... 531
24h -.... 532
Clan ... 533
LA 2 HD ... 40001???? It is no possible!!!
 
You must log in or register to reply here.
Top