Please upload PowerVU EMM Streams - Chat area

Z

zmchu

Registered
Messages
59
xosef1234 said:
@zmchu:
Could you provide emms and emmkey (emmkey via pm in order not to burn this UA) as you did in this post http://www.sat-universe.com/showpost.php?p=2036746772&postcount=68, but

1 for the same channel on same transponder but different UA

and

2 for another channel on another transponder

I need them in order to confirm something. It is important to get more or less the same amount of EMMs.
Thank You so much

(Your EMM listing was very helpful :thum:)
Click to expand...

Good luck:thum:
 
X

xosef1234

Registered
Messages
107
If you have a closer look at the EMMs you will see some kind of structure.
First of all let's take just the first 10 EMMs posted by zmchu (again, thanks for that):
Code: 
82309b5099010e00aa00068f0056bf27000003809f2e376d19d1bc016fa2   2853173820490c6f0ef4359c2476beb2809f63a45f13d45b9b51cb58f4f6   9cb2db47d6c80d73eae76c2cc0809ffcd5d8393ee475e1aa5f30aba7f988   68331a8b1706396b98cb809f65acf5d888a551feb47eae3726661d5f105e   ba4d8ca2287398809f62e1daf5ebf959e2e2cf49fc448f2f1f5a57685746   a9ecff03fb6975bc

82309b5099010e00aa00068f0056bf27000003809f88595f13d45b3851cb   fff4d5e7b23047d6e241731ae77a2cc0809f6192d839a8e4428a15252f1a   3f987a4d167d9402d450ca6dab809f35e1f9f5e2f95909e6cf49fc5f8f2f   095a578357db6eec6903809f6576f5d8b9a55133b47eae3726661d5fe55e   ba4d8c18280b98809f60376919d1bcf013cf6030332ee21bfe0803d3b7c0   eee6ca7cdc4cccab

82309b5099010e004900068f0056bf27000003809ff9376d19d1bcc015f0   4d3910e68d0914dc9246b653c4429052809f6595f5d8c2a53519b47eae97   2666145f155e5e4d8c5fe71798809f8de1f9f5eaf9590931cf49fc608f2f   095a57f157db1cec6903809f63e75f13405bff69cb58f4d59cb2304752c8   4173eaa37a48c0809f61d57839a8e4dc832a9887b5c3ef8e9018f30cec3c   b5f9546a408374db

82309b5099010e005900068f0056bf27000003809f24d5d839a8e4c07841   c659c53ca3e09db308bb7652eada50c6809f65fef5d8c2a50019b47eae2e   2666885f155ee84d8c5fff1798809f1ee1f9f5f4f95909b1cf49fcde8f2f   095a572d57db55ec6903809f609c6d195abca80408b3b4e70983037fa0dc   64025912c66dbf809f63594613d45bffc49958f4d59cb23090d6c8417396   e77a33c04e059b5e

82309b5099010e006b00068f0056bf27000003809fc0376d19d1bc12296d   05bf70a08005aef2ad4e5599a1f294ef809f65ebf5d8c2a54c19b47eae54   2666f85f155eba4d8c5fd51798809febe1f9f5b1f95909aacf49fc078f2f   095a57c857db60ec6903809f63195f13a05bff5ecb58f4d59cb23047d0c8   4173eadd7a31c0809f61d5bb39a8e472c8dead8b181f2dc56aa918680599   542b2b28b60d5685

82309b5099010e005100068f0056bf27000003809fdcd1f5d8c2a54019b4   63ae3744661d5f15f9ba4dfd5f281798809f60e06d19d1bc7d83be593436   a543a9e441b852d1f3fc1720f2809f07e1f9f5aaf95909e2cf49fc7c8f2f   095a57d157dbb8ec6903809f63445f13b65bfff6cb58f4d59cb23047a7c8   4173ea307a3ec0809f61d5a939a8e4c051ef638cc84b63ac8f42db11db41   59c5fe882b876d81

82309b5099010e004a00068f0056bf27000003809fe6d5d839a8e4608f8a   1b7f168f42c423360dc44290056f7b44809f62e5f9f5ebf9cb09aecf49bb   448f5c095a57b457dba9da6903809f43376d19fabc8d7c1f98a12dbec98b   53ff827e645b90d36243809f650df5d830a551bdb47eae3726661d5f105e   ba4d8c5b288598809f63591813d45bff221758f4d59cb23071d6c84173c9   e77a07c0fce729c0

82309b5099010e00c200068f0056bf27000003809f79376d19d1bc1a9ed1   f7ed0f14a199f8b8bd23823394c4340f809f65f8f5d8c2a56719b47eaeca   26665d5f155ea74d8c5f821798809f83e1f9f590f9590994cf49fcb88f2f   095a577157db73ec6903809f614dd839a2e467ecf549b1c477fba00c248b   d008a77421738e809f6359a213d45bff11d658f4d59cb230edd6c841730b   e77a57c0f407a135

82309b5099010e00d000068f0056bf27000003809f14595f13d45bff51cb   28f4d51ab23047d6ae41731be77a2cc0809f65ebf5d8c2a54419b47eae93   2666b25f155e554d8c5f051798809fc4376d19e0bce3741691d98eb82697   30606610e16d60fa8ccb809f61a5d8392ee4491f6e8b7acc43c5824ef325   63ccccd9be8a50809f62e15df5ebf959a641cf49fc448f2f245a5768577f   a9ec5803f0a88850

82309b5099010e00f700068f0056bf27000003809f46e1f9f5ebf95309ae 5a49fcc08f2f095a0b685787a9ec6903809f63025f13d45b5951cb58f405 9cb24347d6c8d573eae7992cc0809f8e376d1925bc5ee743cd1243b1d5f7 e6f77eff2d51165a7292809f6544f5d846a55145b47eae3726661d5f495e ba4d8c0428b198809f61d50839a8e4fd9089548872014f80dc876b4cb479 674a6480cece3208
Since each EMM block is decrypted separately we will concentrate on the first EMM block of each EMM only (for the moment):
Code: 
809f2e376d19d1bc016fa22853173820490c6f0ef4359c2476beb2
809f88595f13d45b3851cbfff4d5e7b23047d6e241731ae77a2cc0
809ff9376d19d1bcc015f04d3910e68d0914dc9246b653c4429052
809f24d5d839a8e4c07841c659c53ca3e09db308bb7652eada50c6
809fc0376d19d1bc12296d05bf70a08005aef2ad4e5599a1f294ef
809fdcd1f5d8c2a54019b463ae3744661d5f15f9ba4dfd5f281798
809fe6d5d839a8e4608f8a1b7f168f42c423360dc44290056f7b44
809f79376d19d1bc1a9ed1f7ed0f14a199f8b8bd23823394c4340f
809f14595f13d45bff51cb28f4d51ab23047d6ae41731be77a2cc0
809f46e1f9f5ebf95309ae5a49fcc08f2f095a0b685787a9ec6903
You can see that e.g. in the first and the third EMM there are a few bytes which are the same (376d19d1bc) but the rest is totally different. However if you continue comparing those blocks you see that the 2nd and the 9th are almost the same. The differences are marked in red:
Code: 
809f[COLOR=Red]88[/COLOR]595f13d45[COLOR=Red][COLOR=Black]b[/COLOR]38[/COLOR]51cb[COLOR=Red]ff[/COLOR]f4d5[COLOR=Red]e7[/COLOR]b23047d6[COLOR=Red]e2[/COLOR]4173[COLOR=Red]1a[/COLOR]e77a2cc0
809f[COLOR=Red]14[/COLOR]595f13d45[COLOR=Red][COLOR=Black]b[COLOR=Red]f[/COLOR][/COLOR]f[/COLOR]51cb[COLOR=Red]28[/COLOR]f4d5[COLOR=Red]1a[/COLOR]b23047d6[COLOR=Red]ae[/COLOR]4173[COLOR=Red]1b[/COLOR]e77a2cc0
I am not an expert in encryption but as far as I know, if a single bit is changed in stream cipher the following bits/bytes differ completely. This means that no stream cipher can be used here (as first step). On the other hand, since the first two bytes seem to be decrypted correctly with the known EMM key, it looks like the regular PowerVu algorithm is still used but those marked bytes are changed afterwards. That's more or less the trick!!

Now continue looking at the EMMs. In the other EMM blocks you can find also almost equal EMMs, even more the same EMM as given in the first block can be found (see EMM 1 and 10 for EMM block 2):
Code: 
809f63[COLOR=Red]a4[/COLOR]5f13d45b[COLOR=Red]9b[/COLOR]51cb58f4[COLOR=Red]f6[/COLOR]9cb2[COLOR=Red]db[/COLOR]47d6c8[COLOR=Red]0d[/COLOR]73eae7[COLOR=Red]6c[/COLOR]2cc0
809f63[COLOR=Red]02[/COLOR]5f13d45b[COLOR=Red]59[/COLOR]51cb58f4[COLOR=Red]05[/COLOR]9cb2[COLOR=Red]43[/COLOR]47d6c8[COLOR=Red]d5[/COLOR]73eae7[COLOR=Red]99[/COLOR]2cc0
EMM 13 and EMM for EMM block 3:
Code: 
809f[COLOR=Red]81[/COLOR]595f13[COLOR=Red]bc[/COLOR]5bff51[COLOR=Red]44[/COLOR]58f4d5[COLOR=Red]68[/COLOR]b23047d6c8[COLOR=Red]09[/COLOR]73ea[COLOR=Red]ee[/COLOR]7a2cc0
809f[COLOR=Red]7f[/COLOR]595f13[COLOR=Red]2f[/COLOR]5bff51[COLOR=Red]68[/COLOR]58f4d5[COLOR=Red]bc[/COLOR]b23047d6c8[COLOR=Red]45[/COLOR]73ea[COLOR=Red]23[/COLOR]7a2cc0
You can do this as well for block 4 and 5. At the end you will find the following structure:
Code: 
1: 80xxyyxxxxxxxxxxyyxxxxyyxxxxyyxxxxxxxxyyxxxxyyxxxxxxxx
2: 80xxxxyyxxxxxxxxyyxxxxxxxxyyxxxxyyxxxxxxyyxxxxxxyyxxxx
3: 80xxyyxxxxxxyyxxxxxxyyxxxxxxyyxxxxxxxxxxyyxxxxyyxxxxxx
4: 80xxxxyyxxxxyyxxxxyyxxxxxxxxxxxxxxxxyyxxxxxxxxyyxxyyxx
5: 80xxxxxxyyxxxxxxxxyyyyxxxxxxxxxxxxyyxxxxxxxxyyxxxxyyxx
yy= bytes which are somehow changed after PowerVu algorithm encryption or bytes which need to be changed before PowerVu algorithm decryption
xx= bytes can be encrypted/decrypted only with PowerVu algorithm; no further processing necessary

Unfortunately, we do not know how these bytes need to be modified. However, you can see in the structure shown above, that if you find the same EMM in the first 3 blocks, you can merge them by just taking known bytes and then you will have an EMM which can be decrypted with the known EMM key:
Code: 
809f63595f13d45bff51cb58f4d59cb23047d6c84173eae77a2cc0
=>
Code: 
800C020900301001220880100028050040BE82040400001956BF27
For the blocks containing ECM keys I could not find repeating bytes. Of course since ECM key changes the EMM block is always different. In any case since we know that only 6 bytes are unknown it could be brute-forced.

Have fun
 
C

C0der

Registered
Messages
267
Yeah, thats the "easy" part. :p
But even with the ECM-key, we get nothing, because we dont know how to modify the ECM before decryption. :(
 
D

drhans

Registered
Messages
116
C0der said:
Yeah, thats the "easy" part. :p
But even with the ECM-key, we get nothing, because we dont know how to modify the ECM before decryption. :(
Click to expand...

Why do you think the ECM key wouldn't work? If the EMM message is "fixed" into the regular PowerVu message, shouldn't it produce the correct ECM key? Because I don't see a way how the ECM key would get back from ISE to IRD, get modified by IRD and then get sent back to ISE. Again I base idea on my standing assumption that there was no modification done to the ISE.
 
D

drhans

Registered
Messages
116
xosef1234 said:
Code: 
1: 80xxyyxxxxxxxxxxyyxxxxyyxxxxyyxxxxxxxxyyxxxxyyxxxxxxxx
2: 80xxxxyyxxxxxxxxyyxxxxxxxxyyxxxxyyxxxxxxyyxxxxxxyyxxxx
3: 80xxyyxxxxxxyyxxxxxxyyxxxxxxyyxxxxxxxxxxyyxxxxyyxxxxxx
4: 80xxxxyyxxxxyyxxxxyyxxxxxxxxxxxxxxxxyyxxxxxxxxyyxxyyxx
5: 80xxxxxxyyxxxxxxxxyyyyxxxxxxxxxxxxyyxxxxxxxxyyxxxxyyxx
Click to expand...

I think this is an amazing discovery. So what's missing is telling how to get those "yy" bytes. I still think the 8th emm byte must be the answer (since the "yy" bytes change depending on this one).
 
X

xosef1234

Registered
Messages
107
drhans said:
I think this is an amazing discovery. So what's missing is telling how to get those "yy" bytes. I still think the 8th emm byte must be the answer (since the "yy" bytes change depending on this one).
Click to expand...
I agree with you that this byte is the key to the trick; I also agree that ISE cannot be modified. As you can see they did not change the encryption/decryption algorithm. They just added another step after/before encryption/decryption. And this is certainly not done in the ISE but in the firmware.

But there is something which does not fit. In case the 8th byte is different those "red-marked" bytes should be different. That's ok. But I've found also some cases where even with the same 8th byte those bytes differ (example of 4th Block):
Code: 
[U]aa[/U]: 809f65 [COLOR=Red]76[/COLOR] f5d8 [COLOR=Red]b9[/COLOR] a551 [COLOR=Red]33[/COLOR] b47eae3726661d5f [COLOR=Red]e5[/COLOR] 5eba4d8c [COLOR=Red]18[/COLOR] 28 [COLOR=Red]0b[/COLOR] 98
[U]aa[/U]: 809f65 [COLOR=Red]ac[/COLOR] f5d8 [COLOR=Red]88[/COLOR] a551 [COLOR=Red]fe[/COLOR] b47eae3726661d5f [COLOR=Red]10[/COLOR] 5eba4d8c [COLOR=Red]a2[/COLOR] 28 [COLOR=Red]73[/COLOR] 98
But this is not always the case as you have already shown in a previous post.
 
Z

zayden

Registered
Messages
61
drhans said:
Why do you think the ECM key wouldn't work? If the EMM message is "fixed" into the regular PowerVu message, shouldn't it produce the correct ECM key? Because I don't see a way how the ECM key would get back from ISE to IRD, get modified by IRD and then get sent back to ISE. Again I base idea on my standing assumption that there was no modification done to the ISE.
Click to expand...
He's implying the raw ecm packets are modified in the same/similar manner before decryption making a found ecm key as useless as a known good emm key currently is.

Great observations xosef.
 
Z

zayden

Registered
Messages
61
My PV knowledge was never that good to begin with... does the cipher decrypt in eight byte blocks or essentially per byte ? If the former and we decrypt the first eight bytes of each block 65535 times we will find the first six bytes of a possible key. Doing the same to a different user in the same emm cycle will do the same. As xosef showed us, and presuming the keys are in different blocks it might be possible to stitch together a valid key.

If C0der is right then even the key is useless without determining the method of byte substitution but maybe having a valid ecm key will help in that endeavour as well.
 
Z

zayden

Registered
Messages
61
I meant does it need to be seeded with eight bytes raw data to begin the process. Otherwise you can decrypt fewer bytes 256 times to reval ecm key bytes and match them against those found in other emms.
 
X

xosef1234

Registered
Messages
107
Some further information:
-within 1 block same non-modified bytes at different positions give different modified bytes => position of non-modified byte is relevant
-in same blocks same non-modified bytes at same positions give different modified bytes depending on other blocks => other blocks are relevant
-whether the 8th byte has an influence cannot be verified but is assumed

In addition, due to the structure of the plain bytes, brute forcing the ECM-keys is possible. E.g. in case the ECM keys are in block 4 the necessary time is even <1sec. ;)
 
Z

zayden

Registered
Messages
61
So retrieving a valid ecm key is not an issue but using it to decrypt video is. Have you looked at that or do you suspect the solutions are related ?
 
Z

zayden

Registered
Messages
61
Btw each block has six wildcards, you can't be bruting 2^48 bits in under a second to retrieve the key so how do you know you have a valid key without using the checksum ? Or do you mean block 5 as it only takes 65k iterations to reveal the key ? (though we still wouldn't know which it is at that point for certain)
 
Last edited:
D

drhans

Registered
Messages
116
zayden said:
So retrieving a valid ecm key is not an issue but using it to decrypt video is. Have you looked at that or do you suspect the solutions are related ?
Click to expand...

Looks like it, I did get both ecm keys fast but they don't work, the ECMs are also modified, I can see that now... there's the same "modifier byte" in ecms too :(

Regular ECM:
Code: 
47 57 72 15 00 81 30 3D 30 37 20 0E 00 00 00 00
MTN ECM:
Code: 
47 57 70 13 00 81 30 3D 50 37 20 0E 00 [COLOR="Red"]5F[/COLOR] 00 00
 
X

xosef1234

Registered
Messages
107
zayden said:
Btw each block has six wildcards, you can't be bruting 2^48 bits in under a second to retrieve the key so how do you know you have a valid key without using the checksum ? Or do you mean block 5 as it only takes 65k iterations to reveal the key ? (though we still wouldn't know which it is at that point for certain)
Click to expand...

If you have a look at the decrypted EMM block you will see a certain structure. So as long as the structure is not changed, brute force can be simplified and therefore accelerated. I was able to do this for 2 different UAs on both 57' and 34'
 
X

xosef1234

Registered
Messages
107
C0der said:
@xosef1234: Makes sense. :)
I'm not sure what exactly you mean. How can bytes be at different positions? (Example?)
Click to expand...

Have a look at this EMM block (block nr.5)
Code: 
809f62e1[COLOR=Red]da[/COLOR]f5ebf959[COLOR=Red]e2e2[/COLOR]cf49fc448f2f[COLOR=Red]1f[/COLOR]5a576857[COLOR=Red]46[/COLOR]a9ec[COLOR=Red]ff[/COLOR]03
The non-modified EMM block is
Code: 
809f62e1f9f5ebf959[COLOR=Lime]09[/COLOR]aecf49fc448f2f[COLOR=Lime]09[/COLOR]5a576857dba9ec6903
You can see that the same byte 09h is modified twice resulting in 2 different modified bytes e2h and 1fh. Therefore the position of the byte to be modified seems to be important.

By the way, can somebody upload a complete ts dump including EMM, ECM and video/audio data? (If possible the UA as posted some posts before should be included ;) )

Thanks
 
You must log in or register to reply here.
Top