Hacking CA system challenge Tandberg [ NO Keys Allowed in Chat Section/s ]

C0der · Jul 6, 2016

So we try 2^49 keys and check 48 bits of the result. How many "false positives" should we expect?

okidokios · Jul 6, 2016

Ok for those who want found the ecm keys for arena or fox europe mux you need to log the ecm/emm pmt pids for more than 3 days and you will get the ecm keys using poc, so the theory that colibri said about the receiver grab the key on eeprom is discarted all you need is patient, what I noticed is that every channel have their own ecm key is not like powervu that open the full tp, and the weird thing is that poc only founded one ecm key of 4 channels from the mux, since my log have a lot of errors cuz my dish sucks, I'm thinking that the other keys were corrupted or maybe they send the keys in different times. By far I can tell you guys all you need is patient and let ur pc recording for a few days.

kebien · Jul 6, 2016

okidokios
But you would only need to log emm,not the full TS,since is the same EMM for all channels,you would find the keys for all channels in the same pid.
I will try the american channels for couple of days.

gotya · Jul 6, 2016

after reading again from the beginning I guess everything is described and tested on the *.ts file uploaded by Colibri.DVB.

my question which I hope I get their answers

Is the encrypted ECM key always located in the EMM with TabId83 that contains our 00 00 16 AB entitlement ID ?

How do we decrypt the encrypted ECM Key that was found in TabId83 ?

Will the poc offline decrypter made by JimBizkit pass to decrypt both of the EVEN and ODD CWs in all Tandberg feeds and channels ?

and how do we know which is active CWs is ? Is it the ODD decrypted CW or the EVEN decrypted CW ?

kebien · Jul 6, 2016

MaRwAn26 said:
Is the encrypted ECM key always located in the EMM with TabId83 that contains our 00 00 16 AB entitlement ID ?

How do we decrypt the encrypted ECM Key that was found in TabId83 ?

Will the poc offline decrypter made by JimBizkit pass to decrypt both of the EVEN and ODD CWs in all Tandberg feeds and channels ?

and how do we know which is active CWs is ? Is it the ODD decrypted CW or the EVEN decrypted CW ?

1-- ECM key is always in EMM pid using table 0x83,but not all 0x83 carry the ECM key

2-- ECM key is decrypted using an EMM encrypted key,which decrypts using the nano E4 key,is a chain of events until you get to the ECM key,each using data coming into the EMM pid.
You the chain in poc : grab nano E4 chunks 0 to 3F,use those to decrypt part of EMM packet to get ECM key,then use ECM key to decrypt ECM.

okidokios · Jul 7, 2016

kebien said:
okidokios
But you would only need to log emm,not the full TS,since is the same EMM for all channels,you would find the keys for all channels in the same pid.
I will try the american channels for couple of days.

Oh well I recorded all pids except the video and audio and private data pids just in case, another thing I noticed is that the ecm keys are the same if the provider use the same id, example if the tandberg id is 1669 for the olympics feed the ecm key will be the same if another provider set the id 1669 for the channel.

dale_para_bajo · Jul 7, 2016

MaRwAn26 said:
...
so I guess the odd CW is in use

does it mean then that these encrypted CW matches with these CW keys
1E 4A E7 F9 A4 F9 CC 33 = 80 XX XX XX XX XX XX 89
6B 76 B5 5C F2 41 CE 16 = 93 XX XX XX XX XX XX 6D

Is it right ??

On Chn2 both cw are used. My best guess is that in yours too.

The PID901 has 2 unique ECMs.
47 43 85 1C 00 80 70 18 EE 16 00 00 00 0B 1E 4A E7 F9 A4 F9 CC 33 6B 76 B5 5C F2 41 CE 16 96 08
47 43 85 1D 00 81 70 18 EE 16 00 00 00 0B 1E 4A E7 F9 A4 F9 CC 33 98 D2 D7 79 62 10 4E B7 D7 E3

That means we have
1 odd
1E 4A E7 F9 A4 F9 CC 33

2 Possible Even
6B 76 B5 5C F2 41 CE 16
98 D2 D7 79 62 10 4E B7

I can not tell you exactly as I am learning too. But I kind of guess that in Channel#2
we use 1rst even then 1rst odd. The last Even I guess is the future one.

I got to that conclusion figuring out what sequence produces the maximum length in the recording.

So for channel#2 I use
01 00 00 00 00 00 00 00 00
00 0D ## ## ## ## ## ## 24
01 33 ## ## ## ## ## ## C1
00 00 00 00 00 00 00 00 00

See how I pad the ModySat cwl with extra CW 00. That how I got my best results.
Now If I change the sequence I loose a small part of 2 seconds of Video.
I have to make notice that this is not the normal. We always some how need to figure this out.

So from what You show I will say that you are correct.

dale_para_bajo · Jul 7, 2016

C0der said:
So we try 2^49 keys and check 48 bits of the result. How many "false positives" should we expect?

Yes, that is why we need to test cw. To validate.

Do you guys have a quick method to validate a cw?
I have 0 experience with CSA.

Any Ideas?

dale_para_bajo · Jul 7, 2016

Also what confuse me is

look at http://www.sat-universe.com/showpost.php?p=2036681021&postcount=20

in DES keys every other 8th bit is a odd parity bit. So key shown

7B 4B ## 9B 22 ## ## 00
is incorrect

It should be
7A 4A ## 9B 23 ## ## 01

I know some one will say who care it does not matters. In fact poc.exe was modify to ignore error in parity.

C0der · Jul 7, 2016

@okidokios:
What do that EMMs look like? Starting with 0x83?

okidokios · Jul 7, 2016

C0der said:
@okidokios:
What do that EMMs look like? Starting with 0x83?

I don't know how to see that, with hex editor? how should I check?

C0der · Jul 7, 2016

Most ts-analyzers should have a hex view.
Hex editor would work too.

Maybe the Logfile of poc has some details.

drhans · Jul 7, 2016

okidokios said:
Oh well I recorded all pids except the video and audio and private data pids just in case, another thing I noticed is that the ecm keys are the same if the provider use the same id, example if the tandberg id is 1669 for the olympics feed the ecm key will be the same if another provider set the id 1669 for the channel.

so what's the ECM key for arena and fox then?

dale_para_bajo · Jul 7, 2016

Listen guys I may be busy in a few days. SO I will post what I have. YES WITH SOURCE.

Listen to make it simple I am using as a STARTING POINT to use for benchmark the DES routines that poc.exe uses. That I guess is the simple option as many has study those sources.

Now Use all as you need but keep in mind it is all your responsibility what you do with knowledge. I am not responsible of what you do with your time.

Please note that there is no legal issue in testing how strong an encryption is. But using the broken codes to do something can go on the wrong direction!. hehehehe

Now I provided 2 binaries for the lazy or the ones that have no knowledge in Code-Blocks.
bftnbrg_normal.exe <== Normal compilation. Windows normally assign resources. This do in my 4 core about

Code:

Keys:           4.194304000000e+006
Time:           1.418083572378e+000
keys per sec:   2.957726950441e+006

bftnbrg_OMP_multycore.exe <== This uses OMP Multicore usually 3 time faster in a 4 core device.

Code:

Keys:           1.258291200000e+007
Time:           9.885997547120e-001
keys per sec:   1.272801448718e+007

10^7 this is nice for a starting base line. GPUs should do 10^9 easily, once we develop those programs.

This is how it works.
program is supplyied with Encrypted ODD CW. As a reference I give the program the correct ECM Key. And I gave it a range of range = 0x400000 this is Hex. So the program will start searching for a key 0x400000 keys below the REAL Key so that at the end it can find it. Remember I am trying to develop a study of time.

Just look in the code. You guys do not have to tell me that I suck coding. hehehehe I am not a real programer. I do it for fun.

Here is the file:

http://www27.zippyshare.com/v/4hytP2Us/file.html

Enjoy.
I try to work it more when I have time as to create a real bruteforce program. But the smart people here can improve it, No Problema.

Now I hope to see marawan26 easy on me. Trust a little friends.

dale_para_bajo · Jul 7, 2016

Upssss!

Test for CW is base on comparison of ONLY bytes 0,1,2,4,5,6 as normally 3 and 7 may change due to cw check sum. Unimportant on the example as the given Clear Text for Comparison is the same!

But C0der is correct as in a real situation many false keys will pop up. We will require a CW Test Method. Any one have a simple way of doing it?

bygfsg · Jul 7, 2016

I think we should check at least two different CWs. If decrypted bytes 0,1,2,4,5,6 match our plain CW, we should try to dercypt next CW(even located in the same ECM - there are two of them in one ECM) with the same key. The key is assumed valid if decrypted bytes 0,1,2,4,5,6 match our second plain CW. Now "false positives" shouldn't appear.

K2TSET · Jul 7, 2016

bygfsg said:
I think we should check at least two different CWs. If decrypted bytes 0,1,2,4,5,6 match our plain CW, we should try to dercypt next CW(even located in the same ECM - there are two of them in one ECM) with the same key. The key is assumed valid if decrypted bytes 0,1,2,4,5,6 match our second plain CW. Now "false positives" shouldn't appear.

Total agree, just as I posted here http://www.sat-universe.com/showpost.php?p=2036684818&postcount=551

I would still like to know if you are absolutely sure the if the last byte of the ECM key for sure will be 00 or if it's due to it listed as 56 bit witout parity bit's?

bygfsg · Jul 7, 2016

Now we can't determine if last byte of ECM key is always zero it depends on system implementation - but there is a high probability. Last byte is 00 not due to parity. Parity bit is located in every byte and is discarded by des algotithm - as we are using standard DES algo with standard key format.

kebien · Jul 7, 2016

I agree,to proof the found ECM key,the next ECM packet change must be decrypted,and one CW must match.

bygfsg
I am not sure what you are saying with

****If decrypted bytes 0,1,2,4,5,6 match our plain CW, we should try to dercypt next CW(even located in the same ECM - there are two of them in one ECM) with the same key. The key is assumed valid if decrypted bytes 0,1,2,4,5,6 match our second plain CW"""

The way I see it there is only one odd and one even CW in a single ECM packet,and are both different.
The only way to find validity is when you use the next ecm change.

We still do not know if the CW checksums are random or follow a process.That information could really be useful since you would know exactly what you are looking for.

gotya · Jul 7, 2016

dale_para_bajo said:
So for channel#2 I use
01 00 00 00 00 00 00 00 00
00 0D ## ## ## ## ## ## 24
01 33 ## ## ## ## ## ## C1
00 00 00 00 00 00 00 00 00

See how I pad the ModySat cwl with extra CW 00. That how I got my best results.
Now If I change the sequence I loose a small part of 2 seconds of Video.
I have to make notice that this is not the normal. We always some how need to figure this out.

So from what You show I will say that you are correct.

that CW key is for channel1 VPID301

+++++++++++++++++++++

the key for channel2 VPID201 is
93 XX XX XX XX XX XX 6D #EVEN
80 XX XX XX XX XX XX 89 #ODD

but I found something interesting

in *.cwl file we should setted as the normal way (BISS Encryption)
therefore each CW has 0 and 1 index like this

Code:

0 93 XX XX XX XX XX XX 6D
1 93 XX XX XX XX XX XX 6D
0 80 XX XX XX XX XX XX 89
1 80 XX XX XX XX XX XX 89

with this way you will then have a complete decrypted output Video *.ts file :thum:

and according to tsdec tool or Modysat tool I noticed that the highest packet reading while decryption is the ODD CW therefore it matches with the ECM encrypted CW key {1E 4A E7 F9 A4 F9 CC 33}

MaRwAn26 said:
47 43 85 1E 00 80 70 18 EE 16 00 00 00 0B 1E 4A E7 F9 A4 F9 CC 33 6B 76 B5 5C F2 41 CE 16 96 08

CWL line 10: ignored:
CWL line 11: ignored:
CWL line 12: ignored:
"C:\Biss\Modysat\ModySat\ModySat\ModySat.cwl": 12 lines, 4 cws loaded.
writing decrypted stream to X:\ModySat\ModySat\FTS-Caracol_Alterno_3785_H_5200_20160702_2033_VPID_201 07-06 16-30-25_decrypted.ts
trying to sync...
sync at packet 56. using CW #0 "0 93 XX XX XX XX XX XX 6D"
packet 26931. using CW #1 "1 93 XX XX XX XX XX XX 6D"
lost sync at packet 26996. Trying resync.
sync at packet 27007. using CW #3 "1 80 XX XX XX XX XX XX 89"
end of TS input file reached. Total number of packets: 35443.
resynced 1 time(s). Decrypted stream has discontinuity and may be unplayable.
total time 0.91s (39193 packets/s, 7.03 MB/s)

look at this shot from the hidden video of channel2 which wasn't exist before :thum:

+++++++++++++++++++++

and in Channel1 VPID301

the cwl file should be formated as this

Code:

0 0D XX XX XX XX XX XX 24   
1 0D XX XX XX XX XX XX 24   
0 33 XX XX XX XX XX XX C1 
1 33 XX XX XX XX XX XX C1

Hacking CA system challenge Tandberg [ NO Keys Allowed in Chat Section/s ]

C0der

Senior Member

okidokios

Member

kebien

Well Known Member

gotya

kebien

Well Known Member

okidokios

Member

dale_para_bajo

Well Known Member

dale_para_bajo

Well Known Member

dale_para_bajo

Well Known Member

C0der

Senior Member

okidokios

Member

C0der

Senior Member

drhans

Senior Member

dale_para_bajo

Well Known Member

dale_para_bajo

Well Known Member

bygfsg

K2TSET

Senior Member

bygfsg

kebien

Well Known Member

gotya

Hacking CA system challenge *Tandberg [ NO Keys Allowed in Chat Section/s ]*

Senior Member

Member

Well Known Member

Well Known Member

Member

Well Known Member

Well Known Member

Well Known Member

Senior Member

Member

Senior Member

Senior Member

Well Known Member

Well Known Member

Senior Member

Well Known Member

Hacking CA system challenge Tandberg [ NO Keys Allowed in Chat Section/s ]