This is what I read in a text:
"In my previous paper the "Cryptanalysis of PowerVu television broadcast encryption" [1] I have described how it was possible find out the ECM key that can decrypt the video & audio DES keys. For this old hack a security chip was necessary that had valid keys inside. A special hacking hardware (for the old timing and the new key change interruption attack) was necessary also.
For the new hack the security chip isn't needed. A self build hacking hardware isn't needed too.
As hardware only a DVB-S2 card and a graphic card that supports CUDA is needed.
To find some management keys it has taken me one day (GeForce GTX 470). A slower card need more time.
It's a brute fore attack on the EMMs, but because of multiple security flaws in the PowerVu system it isn't necessary to test the full 56 bit key space to find a key.
The audio & video gets encrypted by a random DES key. The DES key will change after a few seconds.
The DES key gets encrypted by the PowerVu algorithm and the Entitlement Control Message (ECM) key. Typically the ECM key will change after months or years. The security chips (ISEs) within a provider will have the same ECM key.
The ECM key gets encrypted by the PowerVu algorithm and the Entitlement Management Messages (EMM) key. Each ISE has individual EMM keys. Each ISE has a unique address (UA) also. There is a permanent EMM stream loop for all subscribed ISEs.
I saw also EMMs for ISEs that are not subscribed anymore, but the decrypted ECM key shows that the ECM key is invalid (fake key). A valid key typically has 7 random looking bytes (with the exception of some channels on 5E and 1W that have a very simple ECM key),
but all fake keys I have seen starts with the three bytes "00 00 30". So the provider can overwrite a valid key with a fake key to make the ISE useless.
Some details of the PowerVu algorithm can be found in my previous papers, the remaining details can be extracted from the ISE firmware [2]
But to break an EMM key by a brute force attack it's not enough to know the algorithm. We need also a corresponding cipher/plain text pair to verify that our random EMM key we tried is correct.

Here is an example of an EMM:
82 30 9B 10 99 01 0E 00 00 00 06 8F 00 5D 9C 8A 00 00 03
80 C2 72 68 28 3F F8 AF F8 16 13 FE D6 4D 95 32 AB 95 B2 F4 89 3F E8 62 3F 2B C3
80 C2 70 4B 2F 7F 5A 61 64 6B D0 D7 E7 24 B2 F7 F5 A6 16 46 BD 0D 7E 74 3F 34 61
80 C2 73 F6 BF 91 C9 F0 A1 25 40 EF 65 18 6D 52 66 62 C0 54 1C 0E F0 73 2E 3D 64
80 C2 71 EE 2F 4B D4 09 6C CD D0 67 6B 2E E2 F4 BD 40 96 CC DD 06 76 B4 FD 15 75
80 C2 76 DE 87 93 46 D1 7C 49 D6 0B E3 BD E8 79 34 6D 17 C4 9D 60 BE 3B B0 7B 66
5D F7 E4 01 (crc32)
The first line starts with the table id (82) and shows unencrypted info like the UA (00 5D 9C 8A) of the ISE that should process this EMM.
Each of the next 5 lines have a fixed length and contains one plain text header (80) that indicates that the remaining data is encrypted by an EMM key and should be forwarded by the IRD to the ISE. So the ISE can decrypt the EMM and store the data to the internal EEPROM.
The last line shows the 4 byte crc32 check-sum of the previous data.
Not all the five blocks for the ISE are used to update the ECM key.
There is not only one ECM key, instead there are two ECM keys (called even and odd key).
One key is in use, the other key can be changed. Lets say the even key is in use. For a key change the provider will send the same even key but a new odd key. After all ISEs have received the keys the provider will use the odd key to encrypt the ECM.
The plain ECM header will indicate if the even or the odd key must used to decrypt the ECM. So there is no outage at the customer side during a key change.
So one block is used to update the even ECM key and even tiers.
One block is used to update the odd ECM key and odd tiers.
One block is used to update the even extended tiers and even blackout codes. One block is used to update the odd extended tiers and odd blackout codes. One block is used to update blackout codes, location and lat comp.
Take a look at the 5 blocks and ignore the first 3 bytes that look similar. Do you see the pattern in some of the blocks?
Here is one block with a pattern:
80 C2 70 4B 2F 7F 5A 61 64 6B D0 D7 E7 24 B2 F7 F5 A6 16 46 BD 0D 7E 74 3F 34 61
It's easier if we remove the spaces:
80C2704B2F7F5A61646BD0D7E724B2F7F5A61646BD0D7E743F3461
OK, on the next page I will reveal it.
80C2704B2F7F5A61646BD0D7E724B2F7F5A61646BD0D7E743F3461
You can see two times the pattern 4B2F7F5A61646BD0D7E7 in an encrypted block.
Only a bad algorithm shows pattern in an encrypted stream.
The PowerVu algorithm is a stream cipher with a 56 bit key. The key is the state of the shift register.
The output function (S-Box) is complex, but the security flaw is that the logic (the two XORs) that produce the next internal state from the current state and the plain text during an encryption is to simple.
So when encryption a series of 0 bits the internal state will repeat and you can see the above pattern in the encrypted block. An other security flaw is of course the small key size of 56 bits only.
Here a picture of the PowerVu algorithm that is used for decryption. For encryption swap the arrows on the bottom so that they point from right to left:
So we can assume when we see a long pattern e.g. the 10 bytes in the encrypted block that the corresponding plain text is 0.
So when we see the pattern we have the needed crypt and plain text pair that we need for the brute force attack.

After the key was found you can see the following plain text. The place holder (XX) represents the even ECM key and the (YY) represents the odd ECM key. The last three bytes (5D 9C 8A) must match the last three bytes of the UA or the ISE will drop the block.
80 0C 00 XX XX XX XX XX XX XX 7F FF FF FF FF FF FF FF FF FF FF FF F8 04 5D 9C 8A 80 0C 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 5D 9C 8A 80 0C 01 YY YY YY YY YY YY YY 7F FF FF FF FF FF FF FF FF FF FF FF F8 04 5D 9C 8A 80 0C 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 5D 9C 8A 80 0C 06 C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5D 9C 8A
To make a brute force attack the length of the known plain text should be a little bit larger than the key. If you encrypt a much longer plain text the brute force attack would take unnecessary longer.
I have taken 9 bytes (72 x '0' bits) and encrypted it with different keys and checked if the encrypted pattern match.
Even with the small 56 bit key space and the CUDA system that can try a few hundred keys in parallel this will take to long. So the trick is not to compare the encrypted '0' bits with one EMM, but with more than 131072 (17 bit).
So you need to try only a 39 bit key space instead of 56 bit to find a key.
So I have first recorded nearly all PowerVu EMMs of the different providers I got.
Then I have made a program that scans all the EMM files for a pattern that is at least 9 bytes long and is present twice in a block. Than the program save a 256*256*256*9 byte table to a file.
The other CUDA program do only a single look-up to check if the encrypted text match the pattern. It takes the first 3 bytes of the 9 bytes pattern multiplied by 9 and use it as an offset for the look-up table. So the compare function after a key try is very fast.
AFN has the most subscribers and therfore the most EMMs with a pattern, so you will get most likely an AFN key first.
But back to the plain text block:
80 0C 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 5D 9C 8A
Ignore always the first header byte (80), because it's never encrypted. For us only the payload is interesting.
You can see that the pattern don't start at the first payload byte. If it would, a found key is directly the EMM key that can be used to decrypt the two blocks that contains the even/odd ECM keys. Typically the pattern will occur at an offset of 16 or 20 bits.
So the key is always only the pattern key instead of the EMM key.
A key is always the internal state of the 56 bit shift register.
So we need the state that the shift register had 16 bits before. If we manage this then we have the EMM key. So we need do to the singe steps during the decryption of a single bit backwards (e.g. shift the register to the other direction swap some XOR input/output ports).
It's possible that two previous stats will produce the same encrypted bits. So you must test both when doing the next step backward.
After that you may be have 4 possible states or maybe only 1 again because 3 of the 4 states produce an encrypted bit that doesn't match our encrypted bit.
To keep the possible intermediate states and the final possible EMM key low we need to know as much as possible plain text of the 16 bits.
The typical plain text of the 16 bits is the following:
00001100 00000xxx
For the case you got more than one possible EMM key you can decrypt one of the remaining 4 blocks. If the last three bytes of the decrypted block match the last three bytes of the UA that are present unencrypted in the header of the EMM your key is valid.
Typically max. only a few keys must be tested.
If you collect the 9 bytes patterns for your look-up table, don't take only one pattern per EMM, instead take all up to three pattern that you can be found in the blocks. So you will find faster a key during the brute force attack."
