Not found c8 in hvec feeds

[juankrlos]

hi SU good night,
i'm trying to find C8 from hvec feeds but not found correct C8
i'm testing in csa raimbow table tool:

Using payload size: 184
PID: 21h B8h-Crypt8:73 FC 7D BB 82 FA B1 F5 [E] Count:8
PID: 21h B8h-Crypt8:32 6D 1D 8D 60 AB 26 02 [E] Count:6
PID: 21h B8h-Crypt8:2B F9 FF 83 52 00 79 98 [E] Count:4
PID: 21h B8h-Crypt8:7A 0D C2 9D 13 40 59 0D [E] Count:3
PID: 21h B8h-Crypt8:0A 47 99 0C 35 32 35 5D [E] Count:2
PID: 21h B8h-Crypt8:59 3A E3 71 23 AB 80 AA [E] Count:2
PID: 21h B8h-Crypt8:8C 62 A6 F7 15 D0 E8 76 [E] Count:2

Time for searching Crypt8 = 2 sec.

I have also tried hexadecimal analysis (bash script + dvbsnoop) by counting how many times the hex values are repeated in the common positions where the C8 is located and I get the same result as in the CSA tool v1.23 .
I leave the capture in case someone is curious and finds out what is happening. I have more example captures if anyone is interested

Capture file for analysis:

797.08 MB file on MEGA

mega.nz

 

[Ratzvan]

Unfortunatly not always feeds return good crypt8, above all hvec ones
You need to more patient and wait for a good one

 

[moonbase]

hi SU good night,
i'm trying to find C8 from hvec feeds but not found correct C8
i'm testing in csa raimbow table tool:

Have you got a satellite receiver that can try to automatically find the CW?
They can sometimes get a CW if there is no Crypt8 in your ts file recording?

 

[juankrlos]

Have you got a satellite receiver that can try to automatically find the CW?
They can sometimes get a CW if there is no Crypt8 in your ts file recording?

Yes, it's just curiosity and trying to understand what's going on.
I'm just watching the stream with dvbsnoop and tbs card

 

[moonbase]

Yes, it's just curiosity and trying to understand what's going on.
I'm just watching the stream with dvbsnoop and tbs card

Did your auto satellite receiver clear the picture for you, ie, did it find the CW?

 

[moonbase]

hi SU good night,
i'm trying to find C8 from hvec feeds but not found correct C8
i'm testing in csa raimbow table tool:

Using payload size: 184
PID: 21h B8h-Crypt8:73 FC 7D BB 82 FA B1 F5 [E] Count:8
PID: 21h B8h-Crypt8:32 6D 1D 8D 60 AB 26 02 [E] Count:6
PID: 21h B8h-Crypt8:2B F9 FF 83 52 00 79 98 [E] Count:4
PID: 21h B8h-Crypt8:7A 0D C2 9D 13 40 59 0D [E] Count:3
PID: 21h B8h-Crypt8:0A 47 99 0C 35 32 35 5D [E] Count:2
PID: 21h B8h-Crypt8:59 3A E3 71 23 AB 80 AA [E] Count:2
PID: 21h B8h-Crypt8:8C 62 A6 F7 15 D0 E8 76 [E] Count:2

Time for searching Crypt8 = 2 sec.

I have also tried hexadecimal analysis (bash script + dvbsnoop) by counting how many times the hex values are repeated in the common positions where the C8 is located and I get the same result as in the CSA tool v1.23 .
I leave the capture in case someone is curious and finds out what is happening. I have more example captures if anyone is interested

Capture file for analysis:

797.08 MB file on MEGA

mega.nz

Not sure if you managed to get the CW from the HEVC ts file you attached above.
It looks like it was ultra wide screen format?

 

[dvlajkovic]

That's interlaced HEVC feed for TNT network.
Feed is being auto-scaled to 1920x1080i by the HW / SW the operator is using.
Play it using MPC-HC and should be fine.

 

[moonbase]

That's interlaced HEVC feed for TNT network.
Feed is being auto-scaled to 1920x1080i by the HW / SW the operator is using.
Play it using MPC-HC and should be fine.

The picture was just a quick screen grab from VLC that was playing the ts file recording uploaded to the original post of the topic.
I have not used MPC-HC before, does it come with a default set of codecs as part of its install?

 

[dvlajkovic]

Yes it does.
However I have installed additional LAV Filters and am using them as external filters along with MPC-HC.
You can easily configure both MPC-HC and LAV Filters to provide the best possible support of your PC config.

 

[juankrlos]

Not sure if you managed to get the CW from the HEVC ts file you attached above.
It is listed below if you need it together with a picture of the feed content.

It looks like it was ultra wide screen format?

CW: 55 6F 13 D7 57 AA A1 A2
.
View attachment 39891

How could you get the key? with any satellite receiver? or brute force method?


I am analyzing the TS file with dvbsnoop and I cannot see the C8, the csa RBT cannot find a valid c8 either

 

[juankrlos]

How could you get the key? with any satellite receiver? or brute force method?


I am analyzing the TS file with dvbsnoop and I cannot see the C8, the csa RBT cannot find a valid c8 either

My manual search c8 is based on the definitions of this chat :

crypt8 definitions?

Please do not read bellow this line. Thank for your curosity. This thread is NOT about CSA RBT Chains. NO Creation, merging, modifying, HDD or space requirement stuff,etc. So if that is what you are looking for: Please do not read bellow this line. Thank for your curosity. I am aware of...

www.sat-universe.com

that works perfectly for ts files with h264 codec but not work for hvec :

 

[Me2019H]

My manual search c8 is based on the definitions of this chat :

crypt8 definitions?

Please do not read bellow this line. Thank for your curosity. This thread is NOT about CSA RBT Chains. NO Creation, merging, modifying, HDD or space requirement stuff,etc. So if that is what you are looking for: Please do not read bellow this line. Thank for your curosity. I am aware of...

www.sat-universe.com

see this post

https://www.sat-universe.com/index.php?threads/understanding-des.319704/page-2#post-2037252016

 

[cayoenrique]

@juankrlos

1rst the correct answer was given

...Unfortunatly not always feeds return good crypt8, above all hvec ones...

Where good crypt8 means that all CSA RBT show are FAKE crypt8.

...that works perfectly for ts files with h264 codec but not work for hvec..

I am downloading the file to have a look. But before I say anything you we should provide the most obvious reason.

in the Past, the SD/MPEG2 era, the general rules was that the transponder had a lot of FREE/Unused bandwidth as SD channels required very little. This was the reason as to why Channels per Transponder where high, about 24 TV channels
per transponder. And in the past the processing power ( CPU ) of receiver was very little. So providers try to maintain a constant bit ratio. As result PID 0x1FFF was one of the PID with most data on it to maintain constant bit rate of transponder. Never the less to maintain bit rate per channel, MPEG2 streams where force to have LOTS of PADDING ( 0x00 ). As this padding 0x00 where encrypted they finally produce lost of REAL crypt8.

Now in the present HD and UHD are the standard. In general now the required Stream DATA is so high that there is little to nothing FREE space left. Now Channels per Transponder is low. And to maintain bit rate per channel less pad are use and if there is any TS required to send pads then they are sent unencrypted? As result no REAL crypto8 can be found because there is NONE produce.

I will look in to the file downloaded to see if I can find good samples of real or fake.

 

[juankrlos]

@juankrlos

1rst the correct answer was given


Where good crypt8 means that all CSA RBT show are FAKE crypt8.




I am downloading the file to have a look. But before I say anything you we should provide the most obvious reason.

in the Past, the SD/MPEG2 era, the general rules was that the transponder had a lot of FREE/Unused bandwidth as SD channels required very little. This was the reason as to why Channels per Transponder where high, about 24 TV channels
per transponder. And in the past the processing power ( CPU ) of receiver was very little. So providers try to maintain a constant bit ratio. As result PID 0x1FFF was one of the PID with most data on it to maintain constant bit rate of transponder. Never the less to maintain bit rate per channel, MPEG2 streams where force to have LOTS of PADDING ( 0x00 ). As this padding 0x00 where encrypted they finally produce lost of REAL crypt8.

Now in the present HD and UHD are the standard. In general now the required Stream DATA is so high that there is little to nothing FREE space left. Now Channels per Transponder is low. And to maintain bit rate per channel less pad are use and if there is any TS required to send pads then they are sent unencrypted? As result no REAL crypto8 can be found because there is NONE produce.

I will look in to the file downloaded to see if I can find good samples of real or fake.

Hello, thank you very much for helping,

Now I think maybe they are not sending C8, or they are sending it only at the beginning of the transmission.

I have a second capture of 40 minutes (4GB) where I can't find c8 either

I can see that the captures are more voluminous in Gigas compared to captures where it comes in h264, therefore they are using more bandwidth.

Meanwhile I will continue reading the thread " https://www.sat-universe.com/index.php?threads/understanding-des.319704/page-2#post-2037252016 " . since there is information that can help me resolve my post

 

[cayoenrique]

In next post I will show you how I manage to look at files. But you need my windows tools
If you do not have my Windows TS helper tools here is where I explain how to install

You only need to do Lab001

Understanding CSA

Upps I am trying to use my time and be as quick and in the process I am not testing in Windows. I will try to be careful. I am working to put this in Opencl format. So next post should be in GPGPU using Opencl . Hopefully in a few hours If people at home let me work on it.

www.sat-universe.com

Lab002 PART I

Understanding CSA

Upps I am trying to use my time and be as quick and in the process I am not testing in Windows. I will try to be careful. I am working to put this in Opencl format. So next post should be in GPGPU using Opencl . Hopefully in a few hours If people at home let me work on it.

www.sat-universe.com

***Butttttt for ffmpeg Me2019H found this works better.

https://github.com/BtbN/FFmpeg-Builds/releases/download/latest/ffmpeg-master-latest-win64-gpl.zip

After unzip, Just copy the ff***.exe to C:\Apps\home\bin\

 

[cayoenrique]

[WINKEY]+R  CMD [ENTER]
> mkdir "C:\Apps\Home\cryptodir\Labs\hevc"
> cd C:\Apps\Home\cryptodir\Labs\hevc

To eliminate confusion I will make a smaller file and rename HEVC10000.ts

> busybox sh -c "dvbsnoop -if capture_HEVC_VPID-33.ts HEVC.ts -s ts -n 10000 -b  > HEVC10000.ts"

Lets decrypt file so we can compare later. 1rts we add the key to SoftCam.Key

> copy C:\Apps\Home\bin\SoftCam.Key C:\Apps\Home\bin\SoftCam.Key.001
> echo F 4997B8C4 01 556F13D757AAA1A2                  ; capture_HEVC_VPID-33.ts >> C:\Apps\Home\bin\SoftCam.Key

Now Lets decrypt the file. Remember big files depending on you PC it can take a few minutes.

> oetsdec HEVC10000.ts 1 HEVC10000_decrypted.ts

Now Video IS NOT Ultra wide, it does wrongly say so. You can play it back at regular 16:9 with

ffplay -autoexit -hide_banner -vf "setdar=16/9" HEVC10000_decrypted.ts

See how nicely I mean aspect correct the picture it play??? Yes we took too litle sample that is why it hangs at the end.

Only one VPID_0x0021 is encrypted. so lets have two new files with ONLY VPID0x0021. Remeber big files depending on you PC it can take a few minutes each.

> busybox sh -c "dvbsnoop -if HEVC10000.ts -s ts -n 1000 -b 0x0021  > HEVC1000_VPID_0x0021.ts"
> busybox sh -c "dvbsnoop -if HEVC10000_decrypted.ts -s ts -n 1000 -b 0x0021  > HEVC1000_decrypted_VPID_0x0021.ts"

Lets resume. What we did is just to have two separate files of pid 0x0021. One encrypted one not. Now we can look at its contents.

At this point we can quickly see

> busybox od -An -t x1 --width=188 -N 1880 HEVC1000_VPID_0x0021.ts
> busybox od -An -t x1 --width=188 -N 1880 HEVC1000_decrypted_VPID_0x0021.ts

Both show as part

***
47 00 21 22 B7 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
***

Now lest look details only on encrypted, but to simplify lets take 1000 ts lines only.

> busybox od -An -t x1 --width=188 HEVC1000_VPID_0x0021.ts > VPID_0x0021_1000lines.txt

Now lets count all possible lines repetitions, well we can do the opposite county unique then subtract, yes it repeats about 43 times, 1000 - 957 = 43

> type VPID_0x0021_1000lines.txt | busybox sort | busybox uniq -f 4 | busybox wc -l
957

And lets see the ones that repeat

> type VPID_0x0021_1000lines.txt | busybox sort | busybox uniq -f 4 -d
 47 00 21 20 b7 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Now what I have show you is that there is in fact repetition in this hevc. But it does not show as crypt8 because it is not sent encrypted. Instead TS header reads Transport Scrambling Control = 00 Unencrypted and ONLY Adaptation Filed no Payload of size 183 bytes.

 

[C0der]

Maybe you can upload the smaller file and the decrypted one?
Also the sorted VPID_0x0021_1000lines.txt?

 

[cayoenrique]

@C0der

Please see file at: https://www.sat-universe.com/index.php?threads/enriques-upload-files.319748/post-2037253804

 

[C0der]

How does it look like when you decrypt this (2kb):

Download hevc_C8.ts (1.29 KB) now. Fast and easy at workupload.com

Download hevc_C8.ts (1.29 KB) now. Fast and easy at workupload.com

workupload.com

 

[cayoenrique]

@juankrlos the original OP
I do not want to Hijack your post. I guess we are in original thread objective. If you disagree please inform us and we move to some where else.

@C0der

[WINKEY]+R  CMD [ENTER]
> mkdir "C:\Apps\Home\cryptodir\Labs\hevc"
> cd C:\Apps\Home\cryptodir\Labs\hevc

Since hevc_C8.ts has ONLY PID 21 without PAT or PMT, I guess best option to decrypt is tsdec.exe

> tsdec.exe -i hevc_C8.ts -d "55 6F 13 D7 57 AA A1 A2 55 6F 13 D7 57 AA A1 A2" -o hevc_C8_decrypted.ts

Since the file is small we can create a txt file with the binary

> busybox od -An -t x1 --width=188 hevc_C8.ts > hevc_C8.txt
> busybox od -An -t x1 --width=188 hevc_C8_decrypted.ts > hevc_C8_decrypted.txt
> type hevc_C8_decrypted.txt | busybox sort | busybox uniq -f 4 | busybox wc -l
7

So files have 7 188 TS lines. And we can see its contain

> type hevc_C8_decrypted.txt

Lets better see the start of each ts line

>type hevc_C8.txt | busybox cut -b0-66                    
 47 00 21 9c 73 fc 7d bb 82 fa b1 f5 bd 79 6a 2e d2 9b 41 5e d0 4e
 47 00 21 91 32 6d 1d 8d 60 ab 26 02 4a 1a 0c 7e d1 26 43 24 ce f5
 47 00 21 9e 2b f9 ff 83 52 00 79 98 29 f7 16 89 49 f2 c5 a5 13 b2
 47 00 21 9c 7a 0d c2 9d 13 40 59 0d b2 6c c7 7d cd 0e ff 16 a7 c1
 47 00 21 92 0a 47 99 0c 35 32 35 5d 44 65 61 4b e5 48 5c 8f 4d 50
 47 00 21 9a 59 3a e3 71 23 ab 80 aa e0 d5 48 b4 4a a9 15 75 63 e4
 47 00 21 99 8c 62 a6 f7 15 d0 e8 76 f2 49 4b af 9f 57 a1 2a 45 af

> type hevc_C8_decrypted.txt | busybox cut -b0-66
 47 00 21 1c 4c 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 47 00 21 11 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 47 00 21 1e 00 00 01 4c 03 ff ff ff ff ff ff ff ff ff ff ff ff ff
 47 00 21 1c 00 01 4c 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 47 00 21 12 19 69 31 79 de 9b c9 26 00 c0 f0 57 52 72 f8 67 bd c0
 47 00 21 1a 80 8b be 3c 48 9e 10 7d eb 60 00 b9 32 37 52 2f 7c 33
 47 00 21 19 01 4c 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Lets make a BIG NOTE:
1) We are here because we know the CSA Key to decrypt. Without this keys we would have no way to know there is a condition here.
2) That NONE of this lines are in fact valid useful crypt8. At most they are what a few of us call FAKE crypt8.
3) In encrypted file, all lines have TS Headers: 47 00 21 9#
4) This is NOT a continuous part of the original hevc_smaller_files TS file, It may have been put together by C0der. You can see the continuous counter represented by #. Instead to be consecutive {0-F}. We can see
{ C, 3, 0, 0, 9, 0, 1 }. This are not part of the last hevc_smaller_files. I guess C0der finally downloaded the original 795MB file.
5) In TS header last High nibble (4 bits) is always 9 that means in bits
1001
10 - Scrambled with even key
01 - No adaptation field

Now the discovery shows that after the last VCL NALU but previous of the start of 0xFF sequence we can see the following sequence most of the time. Witch is a Filler data NON-VCL NALU. 0000014C03
Just for those that wonder 000001 is NOT a PES Header. This is in fact a NALU Header 000001

You can download the following as reference

https://www.itu.int/rec/T-REC-H.264-201304-S

00 00 01 4c 03

  4    C    0    3
0100 1100 0000 0011 

From T-REC-H.264-201304-S!!PDF-E.pdf:p62

00 00 01 NALU Header
0 forbidden_zero_bit shall be equal to 0
10 nal_ref_idc = 2 ( shall be equal to 0 for all NAL units having nal_unit_type equal to 6, 9, 10, 11, or ***12***.) byte is not 0 instead 2 weird no?
0 1100 nalType = 0C = 12 = Filler data non-VCL

  0    3
0000 0011  ?? ??

I guess that 0000014C03 is announcing that 0xFF are to follow to the end of TS.
I do not know what C0der want me to see, here. In general we can not use CSA RBT here.

But this is similar to a special case I seen on Albertis DTT. I will have to look and think a little to see if something weird can be apply to lower the time needed to find a Brute-force CSA key in this case.