csa attack
- Thread starter AZPower
- Start date
DVB TS full encryption
cracked
For the first time the DVB transport stream (TS)
Full encryption, in which not only parts, such as video and
Audio, but all PIDs (PAT, NIT, PMT, ...) encryption
be cracked. A fully encrypted TS is
a single data via a standard TS-PID tunneled.
Some screenshots of the hacked programs
DVB TS full encryption cracked
Content
2
Tunneled TS 3
Normal ungetunnelter 19
20
Recommendations 20
20
DVB TS full encryption cracked
Introduction
Programs the firm with a key to the Control Word (CW) via encrypted satellite
be transferred, were indeed cracked some time ago. It makes advantage here,
that the key space is too small with only 248 different ways to cope with today's
keep up gigantic computational power of graphics cards to be able to. The Beginning (MPEG header) of
a decrypted video and audio package is always known (byte sequence "00 00 01"). So
simply with brute force every possible keys are tried. The beginning of such a
Package, with the payload unit start indicator (pusi) bit in the TS header always unencrypted,
signaled. Thus, one can, depending on the graphics card, pick the CW within a few weeks.
Therefore, most vendors do not use the Constant CW or Basic Interoperable Scrambling
System (BISS), but CA systems e.g. Nagravision, Cryptoworks, Conax or Viaccess at
every few seconds a new CW is used for encryption.
In contrast to the mere encryption of video and audio, for years, the TS
Full encryption. Here is a complete TS with its many programs and
entire information management PAT, NIT, SDT, EIT, PMT multiplexed into a single data PID. This
PID data is then encrypted with BISS.
On the Internet I found the following comment:
For people in Spain, not the DVB-T can be received, there is a satellite receiver to Televes 5110
receive these programs directly via the Hispasat satellite (30 ° W) to be able to. Such a
Receivers can not just buy, but a licensed dealer Santander, for the Abertis Telecom
works must ensure first that really is not DVB-T reception is possible. Only then will
the dish and the receiver is set up by him.
The problem of hackers was that they no longer knew where within the Data-PID, the
TS contains all the video or audio packets start. Without this evidence for the
Known plaintext fails even the brute-force.
Explains how I still managed to crack the system. Another highlight is the
first time has come to use common scrambling algorithm (CSA)-Rainbow Table. Never before
Page 2
DVB TS full encryption cracked
CWs were cracked with a CSA Rainbow Table. Although it takes to create the unique table
also very long, but that I may have cracked a number of different CWs in minutes.
The next chapter will be limited to the Spanish DVB-T programs on the Hispasat satellite
Are (30 ° W) transmitted, received. I'm interested in feedback on whether there are other
Systems are transferred to an entire data over a single TS-PID tunneled.
The found CWs are not included here.
Tunneled TS
For the analysis I have such an encrypted PID, the TS is a whole tunneled times
be recorded. The relevant frequencies and PIDs I have listed below in the document.
I then convert the binary file in hex and all 188 bytes, which is the standard packet length,
one can add. In column mode, I then the TS packet header (4
Bytes away). Then I sort the rows in order to better recognize patterns.
Byte 0 1 1 1 1 2 3 3 3
Bit 7 6 5 4 7 .0 .0 .0 7th 5th 7th .6 .4 .0 third
Payload Transport Transport Transport Sync PID adaptation Continuity
byte error scrambling unit priority counter field
47h start control indicator control
indicator
Table 1: TS packet header
The result was surprising. Between most lines, which as expected only once
occurred, but were actually seeing again and again to blocks with identical rows.
But how was that possible? MPEG is a very efficient format and even if as a still image
transferred, are similar to a compressed file, no repetitive data
be expected.
While there are in addition to audio and video are other types of packages such as PAT, CAT, NIT, SDT, or
PMT, which are more or less static. But they have in relation to the video packets
far too low in proportion to the TS and many blocks with the same content is not actually
. cause
So I went back and saw me not only an encrypted PID in the TS, but
Statistics from the entire TS.
There were PAT, CAT, NIT, TDT, EMM, PMTs, some encrypted PIDs and PIDs with id 0x1FFF.
The PIDs with ID are transmitted to 0x1FFF Füllpakete of a variable bit rate, the
e.g. by the MPEG video packets is caused to the fixed bit rate has a transponder to
. come
In statistics, the number of packets per PID could be seen. That was very enlightening for
the counters were identical for all encrypted PIDs. This means that encrypted for PIDs
already had a fixed bit rate, and thus they had to include Füllpakete. This means that the
many identical lines in the text file was encrypted and that was Füllpakete entscheident for
the hack. Because the content of Füllpakete is usually static, sometimes an ascending
Page 3
DVB TS full encryption cracked
Byte sequence, but mostly just louder zero bytes. In known plaintext of Full pakets it is possible
once to generate a rainbow table for this plain text. Then you can within
Minutes to hand the encrypted filling block, identical to the number of encrypted
Packets can be seen, the CW can be calculated with the rainbow table.
But why is there not a single line content (the encrypted Fullpaket) who often
occurs, but the contents of 47 lines are present multiple times?
This is due to the multiplexing (tunneling) of a TS together on a single PID. A TS packet, with
his 188 bytes, there is always from 4 header bytes + 184 bytes of payload.
As the payload encrypted PID but are only 184 bytes are available to the TS
include, but not the required 188 bytes. The last four remaining bytes of the first packet
hike to the top of it come the second package and then the remaining 8 bytes of the second package
at the beginning of the third package.
OuterPkt1 InnerPkt1 header header 4 bytes InnerPkt1
Payload of 180 bytes
OuterPkt2 InnerPkt1 payload header 4 bytes 4 bytes of header InnerPkt2 InnerPkt2
Payload of 176 bytes
OuterPkt3 InnerPkt2 payload header of 8 bytes 4 bytes of header InnerPkt3 InnerPkt3
Payload of 172 bytes
OuterPkt4 InnerPkt3 payload header 12
Byte
4-byte header InnerPkt4 InnerPkt4
Payload of 168 bytes
...
OuterPkt44 InnerPkt43 payload header 172
Byte
InnerPkt44 Header 4
Byte
InnerPkt44
Payload of 8 bytes
OuterPkt45 InnerPkt44 payload header 176
Byte
InnerPkt45 Header 4
Byte
InnerPkt45
Payload of 4 bytes
OuterPkt46 InnerPkt45 payload header 180
Byte
InnerPkt46 header 4 bytes
OuterPkt47 InnerPkt46 payload header 184 bytes
To tunnel packets by 46 or 47 packages you need.
Decrypts see the 47 different Fullpakete as follows:
1F FF 47 10 00 00 00 00 <168 more bytes> 00 00 00 00 00 00 00 00
00 00 00 00 47 1F FF 10 <168 more bytes> 00 00 00 00 00 00 00 00
...
00 00 00 00 00 00 00 00 <168 more bytes> 47 1F FF 10 00 00 00 00
00 00 00 00 00 00 00 00 <168 more bytes> 00 00 00 00 47 1F FF 10
00 00 00 00 00 00 00 00 <168 more bytes> 00 00 00 00 00 00 00 00
Based on what known plaintext to the Rainbow Table you can build
. choose I've taken my recent experiments with 184 zero bytes. This has the
Advantage that it is independent of header changes. There's header for the Füllpakete namely
Two variants once static 1F 47 FF 10 and once with incrementing counter 47 1F continuity
FF 10, FF 47 1F 11 47 1F FF 12, ..., 471f FF 1F. When incrementing counter continuity result
Page 4
DVB TS full encryption cracked
then more than 47 variations, however, then a variant occurs much more frequently. This is then
The encrypted with the 184 zero bytes.
But that, of about the same frequent occurring encrypted packets, when one takes
one fixed to the continuity counter to calculate the CW Rainbow Table?
One could of course try all 47 different packages, but the time to
Calculate the CWs extended by this factor.
To solve this problem we must deal with the adaptation field (AF).
In the TS header, there is a two-bit-long "adaptation field control" that indicates whether before the actual
Yet one Payload AF is present. The bits have the following meanings:
00 Reserved
01 No AF, only payload
10 Only AF, no payload
AF 11 is present and Payload
Let us look at an example package with AF and payload:
47 08 37 F2
5F 60 2E 13 12 2D 81 00 B5 0B 80 96 B0 F8 52 00 00 00 00 00
AF 61 50 13 <156 more bytes> 10 05 32 06
The first line is the TS header. In hi-nibble (F) of the last byte are all set bits (1111). The
first two bits are part of the transport scrambling control field and 11 means that the payload
encrypted with the odd-CW (CW-10 would be even, 00 would be unencrypted and 01 is reserved).
The last two 11 bits represent the AF and payload are available.
In the second line of the AF can be seen. The first byte (13h) returns the length of the remaining field AF
at. Total (1 + length byte 13h following), it is 14h = 20 bytes long.
In the third line, the encrypted payload is depicted. If one of the 184 available
bytes of the length of the AF with its 20 bytes that remain then 164 bytes for the payload
left over.
An AF is always transmitted without encryption. It can for example Timestamp (PCR) and Provider
specific data. The content is not relevant for the hack. But it now and then
is available at this provider and always has a length of 20 bytes is critical. It
thus causes the encrypted payload is not a multiple of 8.
Without AF has always 184 bytes payload consisting of 23 blocks of 8 bytes.
With 20 byte payload, the AF has always 164 bytes consisting of 20 blocks of 8 bytes and a
Remainder of 4 bytes.
But why does it help us if the payload length is not a multiple of 8, our hack?
Page 5
DVB TS full encryption cracked
We need to see more detail and how the payload with the Common Scrambling Algorithm
(CSA) is encrypted.
For encryption, the plaintext from front to rear split into 8 blocks and the rest
(Plain Residue) aside for now.
The last 8-byte block is the IV, which is the DVB-CSA is always zero, and then XORed
with the block cipher encrypts the CW. The result is an Intermediate Block (IB). He is
with the penultimate plaintext XORed and then again with the cipher block with the CW
encrypted. The result is the penultimate intermediate block. If you then all IBs
calculated, then the stream cipher is initialized with the CW and the contents of the first IBs.
The first IB is also the first encrypted block. The rest of the IBs
Output of the associated stream ciphers XOR result and the remaining 8 bytes encrypted
long blocks. Now the only time aside Plain residue is used. He is with
linked to the output of the XOR stream cipher and produces the encrypted rest
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
CB1 CB2 CB3 header CB0 ... CBn-1 CR
IB0 IB1 IB2 IB3-1 ... IBn
PB0 PB1 PB2 ... PBn PBn-2-1 PR
SB1 SB2 SB3 SBn-1 SB0
Stream
cipher
init
Block
cipher
encr.
CW
Block
cipher
encr.
CW
Block
cipher
encr.
CW
Block
cipher
encr.
CW
Block
cipher
encr.
CW
IVCW
Figure 1: CSA encryption
Page 6
DVB TS full encryption cracked
When decrypting it works then vice versa, as can be deduced from the following picture:
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
CB1 CB2 CB3 header CB0 ... CBn-1 CR
IB0 IB1 IB2 IB3-1 ... IBn
PB0 PB1 PB2 ... PBn PBn-2-1 PR
SB1 SB2 SB3 SBn-1 SB0
Stream
cipher
init
Block
cipher
decr.
CW
Block
cipher
decr.
CW
Block
cipher
decr.
CW
Block
cipher
decr.
CW
Block
cipher
decr.
CW
IVCW
The unique feature of the encryption of our last four bytes of the payload is then that they did
not from the block cipher, but is only encrypted from the stream cipher.
But why does that help us to identify the one of the 47 variants, the only encrypted zero
there? The CW is still not known to us and therefore we can but do not really like
the 4, only with the stream cipher encrypted bytes, decrypts look.
If we knew, however, that the decrypted bytes to the value 47 10 1F FF have, it would
our problem is solved, because this header with the PID of the 1FFF Füllpaket with its 184 zero bytes
initiates. Thus we could with the payload of the packet following the CW and the Rainbow Table
compute.
If two packets encrypted with the CSA, in which during the first 180 bytes of a single
Bit different, then the encrypted packets differ totally. Even the last 4
Bytes would be totally different because the first intermediate block to initialize the
Stream ciphers are used, would be different and therefore 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 bytes of encrypted identically and only the remaining 4
Bytes are different. The plain text of the last four bytes is different in only one
Bit, then also differ in the two encrypted only 4 bytes at exactly this bit position
and the rest is identical.
Let us both times, the last of the 47 variants (without AF) from above:
Page 7
DVB TS full encryption cracked
00 00 00 00 00 00 00 00 <168 more bytes> 00 00 00 00 47 1F FF 10
00 00 00 00 00 00 00 00 <168 more bytes> 00 00 00 00 00 00 00 00
Also in the packets with AF will be following a 20 byte payload shorter.
00 00 00 00 00 00 00 00 <148 more bytes> 00 00 00 00 47 1F FF 10
00 00 00 00 00 00 00 00 <148 more bytes> 00 00 00 00 00 00 00 00
Even these two encrypted payloads can be seen. These are filtered out of the TS only
The packages have an AF, then only the payload consists of a row and writes the sorted text file
then. Now you will find encrypted blocks, although within the first 160 bytes
identical, but differ in the last 4 bytes.
Since the first 160 bytes are identical, and the keystream of the stream ciphers is identical.
With the stream cipher is:
Plain XOR key = Crypt
Crypt Key = XOR Plain
Plain2 XOR XOR XOR Plain1 Key1 Key2 = Crypt1 XOR Crypt2
Key1 and Key2 there are identical, they can wegkürzen:
Plain1 Plain2 = XOR XOR Crypt1 Crypt2
Now we set the values:
47 0000 00 00 1F FF 10XOR = Crypt1 XOR Crypt2
1F 47 FF 10 = XOR Crypt1 Crypt2
Recording of the following shows how the four payloads:
128 time: ... 66 84 01 8B 49 ED A4 51 7F C2 1A 94 (= 00 00 00 00)
8 times: ... 66 8B 84 01 A4 ED 4E 49 5D C2 80 84 (= 47 1F FF 10)
2 times: ... 66 84 01 8B 5D 54 ED A4 49 C2 A2 84 (= 47 05 DD 10)
3 times: ... 66 8B 84 01 ED A4 49 5D C2 54 A2 8B (DD = 47 05 1F)
Except for the last 4 bytes of the payload part is the same front.
7F 51 1A 94 (Crypt1) XOR 4E 80 84 5D (Crypt2) = 47 1F FF 10 (Plain1
Plain2 XOR)
So is either 51 7F 94 1A of the plaintext 00 00 00 00 80 84 4E and 5D equivalent to 47 1F FF
10 or 51 7F 94 1A corresponds to the plaintext 1F FF 10 47 80 84 4E and 5D corresponds to the plaintext
00 00 00 00.
Only if we assume in this case for 51 7F 94 1A of the plaintext 00 00 00 00 result for the
remaining two lines of reasonable values (start with sync byte = 47h). If only two lines
has, one can assume that the line which occurs more often the plaintext 00 00 00 00
Page 8
DVB TS full encryption cracked
corresponds. Come about equally from both lines, you have to hold twice the cracking attempt
to perform but that's still better than dealing with all 47 variations.
It is now that the plain text ... 47 1F FF 10 corresponding package with the byte sequence 66 8B 84 ...
01 ED A4 49 4E 80 84 5D C2 was filtered in the original TS encrypted on the PID, skips
then the next 4 bytes header in front and has a 184 byte long is encoded Nullbytefolge
with the one in charge of the rainbow table, the CW can be.
But there is not only the variation in the header of 4 bytes starting before the end of the payload:
00 00 00 00 00 00 00 00 <148 more bytes> 00 00 00 00 47 1F FF 10
There are three further variants:
00 00 00 00 00 00 00 00 <148 more bytes> 00 00 00 00 00 47 1F FF
00 00 00 00 00 00 00 00 <148 more bytes> 00 00 00 00 00 00 47 1F
00 00 00 00 00 00 00 00 <148 more bytes> 00 00 00 00 00 00 00 47
The multiplexer is fed to the TS and then creates an encrypted PID,
that is not synchronized with the headers so that they are 4 byte aligned. This is a perfect
Function not needed. I once such a current compared with an older recording
and that was the sync byte to represent different. A simultaneous recording from a
other transponders showed that had not changed the position of the sync byte.
Perhaps the position of the sync byte changes whenever the boot time or multiplexer
short times of contact with the source that feeds the multiplexer breaks.
I even had a record a year ago. At that time, which additionally at 9 degrees East
sent. The CWs are used now still the same at 30 degrees West in use. Presumably
the CWs had never changed. However, not only one comes to the CW
encrypted PIDs are used. Is in the following table No. CW at two different PIDs
same, then it is encrypted with an identical CW:
Freq. PID Prg. CW TV, radio or data \ TSID
(Hex) No. No. Provider \ Org
Program NetID
11222H 7DA 3010 8
SR: 30000ks 7E4 8 3020
(12/08/2011) 3021 8 7E5
7E6 3022 8
7E7 2023 8
7E8 3024 8
11262H 848 3120 4 TV \ RTVE \ La 2 041A
SR: 30000ks TV \ RTVE \ 24 22D4
(08.12.2011)
TV \ RTVE \ Clan
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 9
DVB TS full encryption cracked
R \ RNE \ Radio 5 Todo Noticias
84B 4 3123 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 044D
R \ RNE \ Radio Nacional 22D4
R \ RNE \ Radio 5 Todo Noticias
84F 3127 10
11302H 89D 3205 9
SR: 30000ks 89E 3206 9
(12/08/2011) 3207 89F 9
8A0 3208 9
8A2 3210 9
8AC 3220 9
8AD 3221 9
8AE 3222 9
8AF 3223 9
12D 11653H 1301 5
SR: 19680ks
(08.12.2011)
12F 1303 5
11677H 191 1401 5
SR: 19684ks
(08.12.2011)
192 1402 5
12523V 582 2410 7
SR: 10400ks
(08.12.2011)
12548V 2BD 1701 2 TV \ La Sexta \ 000E laSexta2
SR: 22D4 29600ks
(08.12.2011)
TV \ La Sexta \ laSexta3
TV \ La Sexta \ laSexta HD
TV \ SOGECABLE \ CANAL + Dos
R \ SOGECABLE \ SER
R \ SOGECABLE \ 40 PRINCIPALE S
R \ SOGECABLE \ CADENA DIAL
TV \ TELECINCO \ CUATRO
2BE 1702 2 TV \ Tele5 \ Boing
TV \ Tele5 \ Telecinco HD
000F
22D4
TV \ TELSON \ MTV
TV \ la 10 \ La 10
R \ la 10 \ ABC Punto Radio
2BF 1703 2 TV \ TELEVISION Antena3 \ NITRO
TV \ TELEVISION Antena3 \ Antena3 HD
0010
22D4
R \ Antena3 TELEVISION \ ONDA CERO
R \ Antena3 TELEVISION \ EUROPE FM
R \ Antena3 TELEVISION \ ONDA
Page 10
DVB TS full encryption cracked
MELODIA
TV \ MARCA TV \ TV MARCA
TV \ VEOTV \ 13 TV
TV \ VEOTV \ MundoInteractivo
R \ Cope \ Cope
R \ Radio Maria \ Maria Radio
12631V 11 1F41 1001
SR: 30000ks
(08.12.2011)
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 \ EN LA CASA TIENDA
0002
22D4
12671V 13 1F44 1004
SR: 30000ks 1F45 1005 14
(12/08/2011) 1006 1F46 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 you would need for the 4 possible sync byte positions 4 and rainbow tables, which
based on 4 different plaintexts to crack all PIDs can. The sync byte positions
the different PIDs are so mixed higgledy-piggledy.
However, since several PIDs that have different sync byte positions, with the same CW
been encrypted, it is sufficient that a single sync byte position with their own Rainbow Table
matches. We have calculated the CW then you can take the CW and the other PIDs
. decrypt If the sync byte own position is not there and no one wants another rainbow
Create tables, then one can see in a few weeks again if the sync byte
Positions have changed.
I have this hack only a complete rainbow table for one sync byte
Positions that can crack the 184 zero bytes, created. Therefore, the above table has also
some gaps. If no program name is specified as the CW is not yet known.
If the package with the AF, the last four encrypted bytes to the value 00 00 00 00
represent, at different PIDs was identical, then I have in the table the same CW
No. awarded. Thus, we know not yet found even at the CW's how many there are.
Page 11
DVB TS full encryption cracked
A bad habit that I could find with newer ones is that now Füllpakete
some transponders dynamic ancillary data contained and thus no longer for Rainbow
Tables are suitable.
The first 8 bytes of Füllpakets then contain additional data, the rest are zero.
The first byte is apparently always 01h when additional data are available.
The second byte is 00h.
The third and the fourth byte is a two-byte counter counts up to the one when the multiplexer
Füllpaket one or a Nutzpaket accepts. Thus, it is easy to detect whether there is a
Was packet loss on the transmission path, and even if it was just a package or equal to 20
The fifth and sixth byte is static.
The seventh and eighth byte is the TSID.
A safety measure is apparently not the whole thing. Yes it is used only partially.
Even the 16-bit counter is much too small for a Sicherheismassnahme. All 65536 packets would be
Füllpaket again identical and can therefore be used to create a rainbow table.
That gave me the idea, as plain text to create the rainbow table is not the content of the
Füllpakete to use. A positive side effect is that it will no longer sync with the
Byte position must grapple, but only one and not four rainbow tables needed.
But what are the static data is still in the TS?
There are tables e.g. PAT, CAT, NIT, PMT or TDT are broadcast regularly. The
Tables do not often use the entire payload. The rest of the payload is always 0xFF bytes
replenished. The Time and Date Table (TDT) for example indeed contains only the date and time. That makes only a
few bytes out. Even with generally large packages such as a Network Information Table (NIT), the
span multiple packets can, it is possible that they have two complete packages
needed and the third package only a few bytes. Then in the third package lots 0xFF
Bytes. Even in the video PID's are always the only one AF packages but have no payload.
The AF is then only the program clock reference (PCR) contained all the rest is with 0xFF bytes
replenished.
As plain text just now herzunehmen 184 * FFh (instead of 184 * 00h) is not successful
. lead So many FFh bytes at a time we will not find, since they are used only to populate
be. The trick is in the encrypted PID not to use the packages have the only one payload
of 184 bytes have, but only the packets with AF and payload. As the AF for this provider
is always 20 bytes, the payload only 164 bytes. As we do not build the Rainbow Table
just use the block cipher, stream cipher does not fall even the last 4 bytes
off. So now we need only 160 bytes with the value FFh and this is now no problem
more.
But how does one FFh bytes encrypted?
Page 12
DVB TS full encryption cracked
Filters you want to put out only the TS packets in addition to the payload of a AF (20 bytes)
have. The payload of the 164 bytes, we can write to a text file. Then we sort the
Text file, so the packages have the same initial are to each other. We are interested
only for the rows in each of which the first 160 bytes are identical. Here's an example from the
Practice:
17 times ... 91 04 49 71 B8 04 51 F4 7D 87 8D 8E (= 00 ... 00 00 00 47 1F)
18 times ... 91 B8 04 8D 49 71 04 51 87 91 7D F4 (= ... 00 00 00 00 47 00)
4 times ... 8D 71 91 B8 04 49 F4 04 51 7D 87 92 (= ... 00 00 00 00 47 03)
7 times ... 8D 71 91 B8 04 49 F4 04 51 7D 87 94 (= ... 00 00 00 00 47 05)
201 times ... 91 B8 04 8D 49 71 04 51 C0 F4 7D 91 (= 00 ... 00 00 00 00 00)
13 times ... 27 AD F5 03 23 5B 04 F1 2C B5 37 09 (= ... FF FF FF FF FF FF)
2 times ... 27 AD F5 03 5B 04 F1 2C 23 8F F6 B5 (= ... FF FF FF FF 47 00)
There were two different blocks and found that often occur within the first 160
Bytes are identical.
We are now looking from the first block in each of the last four bytes of the stream cipher with
been encrypted, to.
Each of the first (F4H) the last four bytes is identical and therefore we skip it.
Each of the second byte (7DH) is also identical, and we skip it again.
The third byte is 87h öffters, but only once C0h. One of these values should be decoded, the Sync
Be byte 47h.
But what value is the other Plainbyte?
We know already from the procedure above.
Crypt1 Crypt2 = XOR XOR Plain1 Plain2
But also:
Crypt1 XOR XOR Crypt2 Plain1 = Plain2
87h 47h 00h XOR XOR C0h
The corresponding decrypted C0h 00h apparently, because it often occurs with 201 times.
So the first block with its zeros is apparently not the desired block, because we are looking
to FFh bytes.
So we turn and the second to block remaining.
Here too, the first difference is discernible in the third of four octets.
37h 47h = FFh XOR XOR 8F
It looks better now. The last 4 bytes will need to calculate the CW with the Rainbow
Table no. The first 160 bytes (23 ... 04 F1) range. They correspond to 160 times the byte FFh.
Page 13
DVB TS full encryption cracked
Due to time constraints I'm not a complete rainbow table generated with 160 times FFh, but
was only so much that I calculate the one unknown CW. We went here all about me
Principle, even if this works in practice.
So far we have seen what you plain text for the creation of his Rainbow Table
can use and what the advantages and disadvantages of the various plain text. Also know
us as we come to the cipher text to fit with the rainbow table to calculate the CW
can.
But how do we create a rainbow table and exactly how we calculate it later with the CW?
First you have to read itself by [1] to the principle of rainbow tables to understand.
The CW does have a length of 8 bytes, and therefore would be 264 possible different keys, but
the number of different keys for all receivers is always artificially limited to 248.
Probably have kept the 216 in reserve in case of a crack to the system (eg
Update on Rainbow Tables) it immediately by the full 264 keys using a firmware
again to make sure. Then hopefully there is still enough time for a successor to the CSA
Algorithm to reflect the increased supports key length (AES). It must then naturally
new receivers will be produced to support both versions (eg CSA and AES). If the
End user could then have the new receiver, the new stroke, to encryption
, also change before the 264 keys can be cracked using rainbow tables in practice.
Over the Rainbow Table you can also currently working with 6 bytes for the key.
This key can then be as follows for encryption with CSA extend from 6 to 8 bytes:
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 one can selbt influence on the chain length.
The larger the rainbow table, the faster a CW can later be found, but the more
more disk space will be needed as well.
I chose 10000h (216) chose as chain length. The rainbow table must therefore only
the remaining 248-16 = 232 pairs contain starting and ending value and the CW can still
relatively fast to calculate.
The start value and the final value represents the CW, do not need each 6 bytes within the
Rainbow Table.
The size of the rainbow table is computed as follows:
(6 +6) * 232 = 48 GB
Page 14
DVB TS full encryption cracked
The basic parameters are set and you can start with the generation.
One chooses a 6 byte CW as start value. From the first to the last starting value is always one to
incremented. If you choose 0 as the start value then results in the following range:
00 00 00 00 00 00 ... 00 00 FF FF FF FF
This starting value is very unfavorable. Someone else might from the community even at 0
Start and the resulting 48 GB would be absolutely identical. So a rainbow table covers
not 100% dependent, but the CSA as I think about 66%. During car concatenation of each
10000h elements must constantly namely the entropy of 264 (Crypt block) to 248 (CW length)
be reduced. This inevitably merge a lot of the chains and give the same
Final value.
Translated from German to English from Original info/posted by collibri
cracked
For the first time the DVB transport stream (TS)
Full encryption, in which not only parts, such as video and
Audio, but all PIDs (PAT, NIT, PMT, ...) encryption
be cracked. A fully encrypted TS is
a single data via a standard TS-PID tunneled.
Some screenshots of the hacked programs
DVB TS full encryption cracked
Content
2
Tunneled TS 3
Normal ungetunnelter 19
20
Recommendations 20
20
DVB TS full encryption cracked
Introduction
Programs the firm with a key to the Control Word (CW) via encrypted satellite
be transferred, were indeed cracked some time ago. It makes advantage here,
that the key space is too small with only 248 different ways to cope with today's
keep up gigantic computational power of graphics cards to be able to. The Beginning (MPEG header) of
a decrypted video and audio package is always known (byte sequence "00 00 01"). So
simply with brute force every possible keys are tried. The beginning of such a
Package, with the payload unit start indicator (pusi) bit in the TS header always unencrypted,
signaled. Thus, one can, depending on the graphics card, pick the CW within a few weeks.
Therefore, most vendors do not use the Constant CW or Basic Interoperable Scrambling
System (BISS), but CA systems e.g. Nagravision, Cryptoworks, Conax or Viaccess at
every few seconds a new CW is used for encryption.
In contrast to the mere encryption of video and audio, for years, the TS
Full encryption. Here is a complete TS with its many programs and
entire information management PAT, NIT, SDT, EIT, PMT multiplexed into a single data PID. This
PID data is then encrypted with BISS.
On the Internet I found the following comment:
For people in Spain, not the DVB-T can be received, there is a satellite receiver to Televes 5110
receive these programs directly via the Hispasat satellite (30 ° W) to be able to. Such a
Receivers can not just buy, but a licensed dealer Santander, for the Abertis Telecom
works must ensure first that really is not DVB-T reception is possible. Only then will
the dish and the receiver is set up by him.
The problem of hackers was that they no longer knew where within the Data-PID, the
TS contains all the video or audio packets start. Without this evidence for the
Known plaintext fails even the brute-force.
Explains how I still managed to crack the system. Another highlight is the
first time has come to use common scrambling algorithm (CSA)-Rainbow Table. Never before
Page 2
DVB TS full encryption cracked
CWs were cracked with a CSA Rainbow Table. Although it takes to create the unique table
also very long, but that I may have cracked a number of different CWs in minutes.
The next chapter will be limited to the Spanish DVB-T programs on the Hispasat satellite
Are (30 ° W) transmitted, received. I'm interested in feedback on whether there are other
Systems are transferred to an entire data over a single TS-PID tunneled.
The found CWs are not included here.
Tunneled TS
For the analysis I have such an encrypted PID, the TS is a whole tunneled times
be recorded. The relevant frequencies and PIDs I have listed below in the document.
I then convert the binary file in hex and all 188 bytes, which is the standard packet length,
one can add. In column mode, I then the TS packet header (4
Bytes away). Then I sort the rows in order to better recognize patterns.
Byte 0 1 1 1 1 2 3 3 3
Bit 7 6 5 4 7 .0 .0 .0 7th 5th 7th .6 .4 .0 third
Payload Transport Transport Transport Sync PID adaptation Continuity
byte error scrambling unit priority counter field
47h start control indicator control
indicator
Table 1: TS packet header
The result was surprising. Between most lines, which as expected only once
occurred, but were actually seeing again and again to blocks with identical rows.
But how was that possible? MPEG is a very efficient format and even if as a still image
transferred, are similar to a compressed file, no repetitive data
be expected.
While there are in addition to audio and video are other types of packages such as PAT, CAT, NIT, SDT, or
PMT, which are more or less static. But they have in relation to the video packets
far too low in proportion to the TS and many blocks with the same content is not actually
. cause
So I went back and saw me not only an encrypted PID in the TS, but
Statistics from the entire TS.
There were PAT, CAT, NIT, TDT, EMM, PMTs, some encrypted PIDs and PIDs with id 0x1FFF.
The PIDs with ID are transmitted to 0x1FFF Füllpakete of a variable bit rate, the
e.g. by the MPEG video packets is caused to the fixed bit rate has a transponder to
. come
In statistics, the number of packets per PID could be seen. That was very enlightening for
the counters were identical for all encrypted PIDs. This means that encrypted for PIDs
already had a fixed bit rate, and thus they had to include Füllpakete. This means that the
many identical lines in the text file was encrypted and that was Füllpakete entscheident for
the hack. Because the content of Füllpakete is usually static, sometimes an ascending
Page 3
DVB TS full encryption cracked
Byte sequence, but mostly just louder zero bytes. In known plaintext of Full pakets it is possible
once to generate a rainbow table for this plain text. Then you can within
Minutes to hand the encrypted filling block, identical to the number of encrypted
Packets can be seen, the CW can be calculated with the rainbow table.
But why is there not a single line content (the encrypted Fullpaket) who often
occurs, but the contents of 47 lines are present multiple times?
This is due to the multiplexing (tunneling) of a TS together on a single PID. A TS packet, with
his 188 bytes, there is always from 4 header bytes + 184 bytes of payload.
As the payload encrypted PID but are only 184 bytes are available to the TS
include, but not the required 188 bytes. The last four remaining bytes of the first packet
hike to the top of it come the second package and then the remaining 8 bytes of the second package
at the beginning of the third package.
OuterPkt1 InnerPkt1 header header 4 bytes InnerPkt1
Payload of 180 bytes
OuterPkt2 InnerPkt1 payload header 4 bytes 4 bytes of header InnerPkt2 InnerPkt2
Payload of 176 bytes
OuterPkt3 InnerPkt2 payload header of 8 bytes 4 bytes of header InnerPkt3 InnerPkt3
Payload of 172 bytes
OuterPkt4 InnerPkt3 payload header 12
Byte
4-byte header InnerPkt4 InnerPkt4
Payload of 168 bytes
...
OuterPkt44 InnerPkt43 payload header 172
Byte
InnerPkt44 Header 4
Byte
InnerPkt44
Payload of 8 bytes
OuterPkt45 InnerPkt44 payload header 176
Byte
InnerPkt45 Header 4
Byte
InnerPkt45
Payload of 4 bytes
OuterPkt46 InnerPkt45 payload header 180
Byte
InnerPkt46 header 4 bytes
OuterPkt47 InnerPkt46 payload header 184 bytes
To tunnel packets by 46 or 47 packages you need.
Decrypts see the 47 different Fullpakete as follows:
1F FF 47 10 00 00 00 00 <168 more bytes> 00 00 00 00 00 00 00 00
00 00 00 00 47 1F FF 10 <168 more bytes> 00 00 00 00 00 00 00 00
...
00 00 00 00 00 00 00 00 <168 more bytes> 47 1F FF 10 00 00 00 00
00 00 00 00 00 00 00 00 <168 more bytes> 00 00 00 00 47 1F FF 10
00 00 00 00 00 00 00 00 <168 more bytes> 00 00 00 00 00 00 00 00
Based on what known plaintext to the Rainbow Table you can build
. choose I've taken my recent experiments with 184 zero bytes. This has the
Advantage that it is independent of header changes. There's header for the Füllpakete namely
Two variants once static 1F 47 FF 10 and once with incrementing counter 47 1F continuity
FF 10, FF 47 1F 11 47 1F FF 12, ..., 471f FF 1F. When incrementing counter continuity result
Page 4
DVB TS full encryption cracked
then more than 47 variations, however, then a variant occurs much more frequently. This is then
The encrypted with the 184 zero bytes.
But that, of about the same frequent occurring encrypted packets, when one takes
one fixed to the continuity counter to calculate the CW Rainbow Table?
One could of course try all 47 different packages, but the time to
Calculate the CWs extended by this factor.
To solve this problem we must deal with the adaptation field (AF).
In the TS header, there is a two-bit-long "adaptation field control" that indicates whether before the actual
Yet one Payload AF is present. The bits have the following meanings:
00 Reserved
01 No AF, only payload
10 Only AF, no payload
AF 11 is present and Payload
Let us look at an example package with AF and payload:
47 08 37 F2
5F 60 2E 13 12 2D 81 00 B5 0B 80 96 B0 F8 52 00 00 00 00 00
AF 61 50 13 <156 more bytes> 10 05 32 06
The first line is the TS header. In hi-nibble (F) of the last byte are all set bits (1111). The
first two bits are part of the transport scrambling control field and 11 means that the payload
encrypted with the odd-CW (CW-10 would be even, 00 would be unencrypted and 01 is reserved).
The last two 11 bits represent the AF and payload are available.
In the second line of the AF can be seen. The first byte (13h) returns the length of the remaining field AF
at. Total (1 + length byte 13h following), it is 14h = 20 bytes long.
In the third line, the encrypted payload is depicted. If one of the 184 available
bytes of the length of the AF with its 20 bytes that remain then 164 bytes for the payload
left over.
An AF is always transmitted without encryption. It can for example Timestamp (PCR) and Provider
specific data. The content is not relevant for the hack. But it now and then
is available at this provider and always has a length of 20 bytes is critical. It
thus causes the encrypted payload is not a multiple of 8.
Without AF has always 184 bytes payload consisting of 23 blocks of 8 bytes.
With 20 byte payload, the AF has always 164 bytes consisting of 20 blocks of 8 bytes and a
Remainder of 4 bytes.
But why does it help us if the payload length is not a multiple of 8, our hack?
Page 5
DVB TS full encryption cracked
We need to see more detail and how the payload with the Common Scrambling Algorithm
(CSA) is encrypted.
For encryption, the plaintext from front to rear split into 8 blocks and the rest
(Plain Residue) aside for now.
The last 8-byte block is the IV, which is the DVB-CSA is always zero, and then XORed
with the block cipher encrypts the CW. The result is an Intermediate Block (IB). He is
with the penultimate plaintext XORed and then again with the cipher block with the CW
encrypted. The result is the penultimate intermediate block. If you then all IBs
calculated, then the stream cipher is initialized with the CW and the contents of the first IBs.
The first IB is also the first encrypted block. The rest of the IBs
Output of the associated stream ciphers XOR result and the remaining 8 bytes encrypted
long blocks. Now the only time aside Plain residue is used. He is with
linked to the output of the XOR stream cipher and produces the encrypted rest
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
CB1 CB2 CB3 header CB0 ... CBn-1 CR
IB0 IB1 IB2 IB3-1 ... IBn
PB0 PB1 PB2 ... PBn PBn-2-1 PR
SB1 SB2 SB3 SBn-1 SB0
Stream
cipher
init
Block
cipher
encr.
CW
Block
cipher
encr.
CW
Block
cipher
encr.
CW
Block
cipher
encr.
CW
Block
cipher
encr.
CW
IVCW
Figure 1: CSA encryption
Page 6
DVB TS full encryption cracked
When decrypting it works then vice versa, as can be deduced from the following picture:
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
CB1 CB2 CB3 header CB0 ... CBn-1 CR
IB0 IB1 IB2 IB3-1 ... IBn
PB0 PB1 PB2 ... PBn PBn-2-1 PR
SB1 SB2 SB3 SBn-1 SB0
Stream
cipher
init
Block
cipher
decr.
CW
Block
cipher
decr.
CW
Block
cipher
decr.
CW
Block
cipher
decr.
CW
Block
cipher
decr.
CW
IVCW
The unique feature of the encryption of our last four bytes of the payload is then that they did
not from the block cipher, but is only encrypted from the stream cipher.
But why does that help us to identify the one of the 47 variants, the only encrypted zero
there? The CW is still not known to us and therefore we can but do not really like
the 4, only with the stream cipher encrypted bytes, decrypts look.
If we knew, however, that the decrypted bytes to the value 47 10 1F FF have, it would
our problem is solved, because this header with the PID of the 1FFF Füllpaket with its 184 zero bytes
initiates. Thus we could with the payload of the packet following the CW and the Rainbow Table
compute.
If two packets encrypted with the CSA, in which during the first 180 bytes of a single
Bit different, then the encrypted packets differ totally. Even the last 4
Bytes would be totally different because the first intermediate block to initialize the
Stream ciphers are used, would be different and therefore 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 bytes of encrypted identically and only the remaining 4
Bytes are different. The plain text of the last four bytes is different in only one
Bit, then also differ in the two encrypted only 4 bytes at exactly this bit position
and the rest is identical.
Let us both times, the last of the 47 variants (without AF) from above:
Page 7
DVB TS full encryption cracked
00 00 00 00 00 00 00 00 <168 more bytes> 00 00 00 00 47 1F FF 10
00 00 00 00 00 00 00 00 <168 more bytes> 00 00 00 00 00 00 00 00
Also in the packets with AF will be following a 20 byte payload shorter.
00 00 00 00 00 00 00 00 <148 more bytes> 00 00 00 00 47 1F FF 10
00 00 00 00 00 00 00 00 <148 more bytes> 00 00 00 00 00 00 00 00
Even these two encrypted payloads can be seen. These are filtered out of the TS only
The packages have an AF, then only the payload consists of a row and writes the sorted text file
then. Now you will find encrypted blocks, although within the first 160 bytes
identical, but differ in the last 4 bytes.
Since the first 160 bytes are identical, and the keystream of the stream ciphers is identical.
With the stream cipher is:
Plain XOR key = Crypt
Crypt Key = XOR Plain
Plain2 XOR XOR XOR Plain1 Key1 Key2 = Crypt1 XOR Crypt2
Key1 and Key2 there are identical, they can wegkürzen:
Plain1 Plain2 = XOR XOR Crypt1 Crypt2
Now we set the values:
47 0000 00 00 1F FF 10XOR = Crypt1 XOR Crypt2
1F 47 FF 10 = XOR Crypt1 Crypt2
Recording of the following shows how the four payloads:
128 time: ... 66 84 01 8B 49 ED A4 51 7F C2 1A 94 (= 00 00 00 00)
8 times: ... 66 8B 84 01 A4 ED 4E 49 5D C2 80 84 (= 47 1F FF 10)
2 times: ... 66 84 01 8B 5D 54 ED A4 49 C2 A2 84 (= 47 05 DD 10)
3 times: ... 66 8B 84 01 ED A4 49 5D C2 54 A2 8B (DD = 47 05 1F)
Except for the last 4 bytes of the payload part is the same front.
7F 51 1A 94 (Crypt1) XOR 4E 80 84 5D (Crypt2) = 47 1F FF 10 (Plain1
Plain2 XOR)
So is either 51 7F 94 1A of the plaintext 00 00 00 00 80 84 4E and 5D equivalent to 47 1F FF
10 or 51 7F 94 1A corresponds to the plaintext 1F FF 10 47 80 84 4E and 5D corresponds to the plaintext
00 00 00 00.
Only if we assume in this case for 51 7F 94 1A of the plaintext 00 00 00 00 result for the
remaining two lines of reasonable values (start with sync byte = 47h). If only two lines
has, one can assume that the line which occurs more often the plaintext 00 00 00 00
Page 8
DVB TS full encryption cracked
corresponds. Come about equally from both lines, you have to hold twice the cracking attempt
to perform but that's still better than dealing with all 47 variations.
It is now that the plain text ... 47 1F FF 10 corresponding package with the byte sequence 66 8B 84 ...
01 ED A4 49 4E 80 84 5D C2 was filtered in the original TS encrypted on the PID, skips
then the next 4 bytes header in front and has a 184 byte long is encoded Nullbytefolge
with the one in charge of the rainbow table, the CW can be.
But there is not only the variation in the header of 4 bytes starting before the end of the payload:
00 00 00 00 00 00 00 00 <148 more bytes> 00 00 00 00 47 1F FF 10
There are three further variants:
00 00 00 00 00 00 00 00 <148 more bytes> 00 00 00 00 00 47 1F FF
00 00 00 00 00 00 00 00 <148 more bytes> 00 00 00 00 00 00 47 1F
00 00 00 00 00 00 00 00 <148 more bytes> 00 00 00 00 00 00 00 47
The multiplexer is fed to the TS and then creates an encrypted PID,
that is not synchronized with the headers so that they are 4 byte aligned. This is a perfect
Function not needed. I once such a current compared with an older recording
and that was the sync byte to represent different. A simultaneous recording from a
other transponders showed that had not changed the position of the sync byte.
Perhaps the position of the sync byte changes whenever the boot time or multiplexer
short times of contact with the source that feeds the multiplexer breaks.
I even had a record a year ago. At that time, which additionally at 9 degrees East
sent. The CWs are used now still the same at 30 degrees West in use. Presumably
the CWs had never changed. However, not only one comes to the CW
encrypted PIDs are used. Is in the following table No. CW at two different PIDs
same, then it is encrypted with an identical CW:
Freq. PID Prg. CW TV, radio or data \ TSID
(Hex) No. No. Provider \ Org
Program NetID
11222H 7DA 3010 8
SR: 30000ks 7E4 8 3020
(12/08/2011) 3021 8 7E5
7E6 3022 8
7E7 2023 8
7E8 3024 8
11262H 848 3120 4 TV \ RTVE \ La 2 041A
SR: 30000ks TV \ RTVE \ 24 22D4
(08.12.2011)
TV \ RTVE \ Clan
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 9
DVB TS full encryption cracked
R \ RNE \ Radio 5 Todo Noticias
84B 4 3123 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 044D
R \ RNE \ Radio Nacional 22D4
R \ RNE \ Radio 5 Todo Noticias
84F 3127 10
11302H 89D 3205 9
SR: 30000ks 89E 3206 9
(12/08/2011) 3207 89F 9
8A0 3208 9
8A2 3210 9
8AC 3220 9
8AD 3221 9
8AE 3222 9
8AF 3223 9
12D 11653H 1301 5
SR: 19680ks
(08.12.2011)
12F 1303 5
11677H 191 1401 5
SR: 19684ks
(08.12.2011)
192 1402 5
12523V 582 2410 7
SR: 10400ks
(08.12.2011)
12548V 2BD 1701 2 TV \ La Sexta \ 000E laSexta2
SR: 22D4 29600ks
(08.12.2011)
TV \ La Sexta \ laSexta3
TV \ La Sexta \ laSexta HD
TV \ SOGECABLE \ CANAL + Dos
R \ SOGECABLE \ SER
R \ SOGECABLE \ 40 PRINCIPALE S
R \ SOGECABLE \ CADENA DIAL
TV \ TELECINCO \ CUATRO
2BE 1702 2 TV \ Tele5 \ Boing
TV \ Tele5 \ Telecinco HD
000F
22D4
TV \ TELSON \ MTV
TV \ la 10 \ La 10
R \ la 10 \ ABC Punto Radio
2BF 1703 2 TV \ TELEVISION Antena3 \ NITRO
TV \ TELEVISION Antena3 \ Antena3 HD
0010
22D4
R \ Antena3 TELEVISION \ ONDA CERO
R \ Antena3 TELEVISION \ EUROPE FM
R \ Antena3 TELEVISION \ ONDA
Page 10
DVB TS full encryption cracked
MELODIA
TV \ MARCA TV \ TV MARCA
TV \ VEOTV \ 13 TV
TV \ VEOTV \ MundoInteractivo
R \ Cope \ Cope
R \ Radio Maria \ Maria Radio
12631V 11 1F41 1001
SR: 30000ks
(08.12.2011)
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 \ EN LA CASA TIENDA
0002
22D4
12671V 13 1F44 1004
SR: 30000ks 1F45 1005 14
(12/08/2011) 1006 1F46 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 you would need for the 4 possible sync byte positions 4 and rainbow tables, which
based on 4 different plaintexts to crack all PIDs can. The sync byte positions
the different PIDs are so mixed higgledy-piggledy.
However, since several PIDs that have different sync byte positions, with the same CW
been encrypted, it is sufficient that a single sync byte position with their own Rainbow Table
matches. We have calculated the CW then you can take the CW and the other PIDs
. decrypt If the sync byte own position is not there and no one wants another rainbow
Create tables, then one can see in a few weeks again if the sync byte
Positions have changed.
I have this hack only a complete rainbow table for one sync byte
Positions that can crack the 184 zero bytes, created. Therefore, the above table has also
some gaps. If no program name is specified as the CW is not yet known.
If the package with the AF, the last four encrypted bytes to the value 00 00 00 00
represent, at different PIDs was identical, then I have in the table the same CW
No. awarded. Thus, we know not yet found even at the CW's how many there are.
Page 11
DVB TS full encryption cracked
A bad habit that I could find with newer ones is that now Füllpakete
some transponders dynamic ancillary data contained and thus no longer for Rainbow
Tables are suitable.
The first 8 bytes of Füllpakets then contain additional data, the rest are zero.
The first byte is apparently always 01h when additional data are available.
The second byte is 00h.
The third and the fourth byte is a two-byte counter counts up to the one when the multiplexer
Füllpaket one or a Nutzpaket accepts. Thus, it is easy to detect whether there is a
Was packet loss on the transmission path, and even if it was just a package or equal to 20
The fifth and sixth byte is static.
The seventh and eighth byte is the TSID.
A safety measure is apparently not the whole thing. Yes it is used only partially.
Even the 16-bit counter is much too small for a Sicherheismassnahme. All 65536 packets would be
Füllpaket again identical and can therefore be used to create a rainbow table.
That gave me the idea, as plain text to create the rainbow table is not the content of the
Füllpakete to use. A positive side effect is that it will no longer sync with the
Byte position must grapple, but only one and not four rainbow tables needed.
But what are the static data is still in the TS?
There are tables e.g. PAT, CAT, NIT, PMT or TDT are broadcast regularly. The
Tables do not often use the entire payload. The rest of the payload is always 0xFF bytes
replenished. The Time and Date Table (TDT) for example indeed contains only the date and time. That makes only a
few bytes out. Even with generally large packages such as a Network Information Table (NIT), the
span multiple packets can, it is possible that they have two complete packages
needed and the third package only a few bytes. Then in the third package lots 0xFF
Bytes. Even in the video PID's are always the only one AF packages but have no payload.
The AF is then only the program clock reference (PCR) contained all the rest is with 0xFF bytes
replenished.
As plain text just now herzunehmen 184 * FFh (instead of 184 * 00h) is not successful
. lead So many FFh bytes at a time we will not find, since they are used only to populate
be. The trick is in the encrypted PID not to use the packages have the only one payload
of 184 bytes have, but only the packets with AF and payload. As the AF for this provider
is always 20 bytes, the payload only 164 bytes. As we do not build the Rainbow Table
just use the block cipher, stream cipher does not fall even the last 4 bytes
off. So now we need only 160 bytes with the value FFh and this is now no problem
more.
But how does one FFh bytes encrypted?
Page 12
DVB TS full encryption cracked
Filters you want to put out only the TS packets in addition to the payload of a AF (20 bytes)
have. The payload of the 164 bytes, we can write to a text file. Then we sort the
Text file, so the packages have the same initial are to each other. We are interested
only for the rows in each of which the first 160 bytes are identical. Here's an example from the
Practice:
17 times ... 91 04 49 71 B8 04 51 F4 7D 87 8D 8E (= 00 ... 00 00 00 47 1F)
18 times ... 91 B8 04 8D 49 71 04 51 87 91 7D F4 (= ... 00 00 00 00 47 00)
4 times ... 8D 71 91 B8 04 49 F4 04 51 7D 87 92 (= ... 00 00 00 00 47 03)
7 times ... 8D 71 91 B8 04 49 F4 04 51 7D 87 94 (= ... 00 00 00 00 47 05)
201 times ... 91 B8 04 8D 49 71 04 51 C0 F4 7D 91 (= 00 ... 00 00 00 00 00)
13 times ... 27 AD F5 03 23 5B 04 F1 2C B5 37 09 (= ... FF FF FF FF FF FF)
2 times ... 27 AD F5 03 5B 04 F1 2C 23 8F F6 B5 (= ... FF FF FF FF 47 00)
There were two different blocks and found that often occur within the first 160
Bytes are identical.
We are now looking from the first block in each of the last four bytes of the stream cipher with
been encrypted, to.
Each of the first (F4H) the last four bytes is identical and therefore we skip it.
Each of the second byte (7DH) is also identical, and we skip it again.
The third byte is 87h öffters, but only once C0h. One of these values should be decoded, the Sync
Be byte 47h.
But what value is the other Plainbyte?
We know already from the procedure above.
Crypt1 Crypt2 = XOR XOR Plain1 Plain2
But also:
Crypt1 XOR XOR Crypt2 Plain1 = Plain2
87h 47h 00h XOR XOR C0h
The corresponding decrypted C0h 00h apparently, because it often occurs with 201 times.
So the first block with its zeros is apparently not the desired block, because we are looking
to FFh bytes.
So we turn and the second to block remaining.
Here too, the first difference is discernible in the third of four octets.
37h 47h = FFh XOR XOR 8F
It looks better now. The last 4 bytes will need to calculate the CW with the Rainbow
Table no. The first 160 bytes (23 ... 04 F1) range. They correspond to 160 times the byte FFh.
Page 13
DVB TS full encryption cracked
Due to time constraints I'm not a complete rainbow table generated with 160 times FFh, but
was only so much that I calculate the one unknown CW. We went here all about me
Principle, even if this works in practice.
So far we have seen what you plain text for the creation of his Rainbow Table
can use and what the advantages and disadvantages of the various plain text. Also know
us as we come to the cipher text to fit with the rainbow table to calculate the CW
can.
But how do we create a rainbow table and exactly how we calculate it later with the CW?
First you have to read itself by [1] to the principle of rainbow tables to understand.
The CW does have a length of 8 bytes, and therefore would be 264 possible different keys, but
the number of different keys for all receivers is always artificially limited to 248.
Probably have kept the 216 in reserve in case of a crack to the system (eg
Update on Rainbow Tables) it immediately by the full 264 keys using a firmware
again to make sure. Then hopefully there is still enough time for a successor to the CSA
Algorithm to reflect the increased supports key length (AES). It must then naturally
new receivers will be produced to support both versions (eg CSA and AES). If the
End user could then have the new receiver, the new stroke, to encryption
, also change before the 264 keys can be cracked using rainbow tables in practice.
Over the Rainbow Table you can also currently working with 6 bytes for the key.
This key can then be as follows for encryption with CSA extend from 6 to 8 bytes:
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 one can selbt influence on the chain length.
The larger the rainbow table, the faster a CW can later be found, but the more
more disk space will be needed as well.
I chose 10000h (216) chose as chain length. The rainbow table must therefore only
the remaining 248-16 = 232 pairs contain starting and ending value and the CW can still
relatively fast to calculate.
The start value and the final value represents the CW, do not need each 6 bytes within the
Rainbow Table.
The size of the rainbow table is computed as follows:
(6 +6) * 232 = 48 GB
Page 14
DVB TS full encryption cracked
The basic parameters are set and you can start with the generation.
One chooses a 6 byte CW as start value. From the first to the last starting value is always one to
incremented. If you choose 0 as the start value then results in the following range:
00 00 00 00 00 00 ... 00 00 FF FF FF FF
This starting value is very unfavorable. Someone else might from the community even at 0
Start and the resulting 48 GB would be absolutely identical. So a rainbow table covers
not 100% dependent, but the CSA as I think about 66%. During car concatenation of each
10000h elements must constantly namely the entropy of 264 (Crypt block) to 248 (CW length)
be reduced. This inevitably merge a lot of the chains and give the same
Final value.
Translated from German to English from Original info/posted by collibri
Does any any this help me ?
Been on my mind for years to try and get the Spanish terrestrials channels here in Ireland. My interest is learning the language and I could be persuaded to watch the odd football match. I read as much of this as my poor head could take but I don't know if there is a next step from here for me.
Need to upgrade my FTA receiver now as I want to go HD. Any recommendations for a receiver that might eventually allow me to see the Spanish terrestrials over Sat? I don't need one with hard disk. Cheap as possible but one where I could enter the keys for "Spanish TDT over Satellite.
Thnaks
Been on my mind for years to try and get the Spanish terrestrials channels here in Ireland. My interest is learning the language and I could be persuaded to watch the odd football match. I read as much of this as my poor head could take but I don't know if there is a next step from here for me.
Need to upgrade my FTA receiver now as I want to go HD. Any recommendations for a receiver that might eventually allow me to see the Spanish terrestrials over Sat? I don't need one with hard disk. Cheap as possible but one where I could enter the keys for "Spanish TDT over Satellite.
Thnaks
- Messages
- 24,837
Spiderbox 9900HD , Dm800SE HD , Tm5402HD or a cheapo TM500 Super and seek c/s free servers or buy card and start c/s like that you should get D+ spain which covers lots of spainish channels with spiderbox you can even have free gift which allows access to spainish channels for a limited time . i dont wanna go too far off topic here but hopefully this suggestion will help .
----
barney
----
barney