CW Crypt

vladtimmy

Registered
Messages
89
hii all how to finde cw not Checksum

rtb and all not worck
tsdec_gui not worck

95 8F B9 AA B0 D9 F7 A1 #[O] PID:0BFFh
E9 BF 7D 4F A7 5C 13 3C #[E] PID:0BFFh
38 B2 85 4A 3F 4C 68 0A #[O] PID:0BFFh

cw1 0000000000000000F4652D98B7C624B1 corect
cw2 186A401280E6FB330000000000000000 corect
cw3 0000000000000000A40AA30749034E00 corect

CW: F4652D98B7C624B1 crypto calc ghive corect c8
Crypt8-B8hxFFh: 95 8F B9 AA B0 D9 F7 A1

9D 93 5E 20 AF 9F F7 92 #[O] PID:00B5h
84 31 FC CA A2 42 67 01 #[E] PID:00B5h
nead cw
 

kebien

Registered
Messages
1,329
Not sure what you are asking.
For checksums,they are incorrect for the CW given.
CW: F4652D98B7C624B1 checksums would be 86 and A1.
Plus,not sure but apparently the CW are changing from odd to even,so this is not a biss feed.
I would say you need to provide a lot more information about the feed,how is encrypted (since is not biss),and what are you trying to do.
For an hour long encrypted file you would need 360+ CW's for the slowest systems.
 
Last edited:

kebien

Registered
Messages
1,329
You must try to write good english,because what you say makes little sense.
How can your data be correct when cheksums are wrong?
How could you think to use rainbow tables when is not BISS and CW does not have checksums?
Do you understand how RBT works? it can never find any other type of CW that is not CSA,and CSA has checksums.
If the video is not CSA encrypted you must first define how is encrypted.
Without more information is impossible to help.
And I suspect you don't know what you are doing : you using rainbow tables to find CW that have wrong checksums? Rainbow program will NEVER give you a correct CW without correct checksums.
 

Psilos2003

Registered
Messages
52
Very interesting. The .ts file is 13 seconds long. It is not BISS but Videoguard from 19E. CWs change every 5-6 seconds. Even though it is CSA, the CW checksums are wrong. The file properly decrypts using the CWs with the wrong checksums. If the checksums are corrected, it doesn't decrypt.
 

K2TSET

Registered
Messages
125
Very interesting. The .ts file is 13 seconds long. It is not BISS but Videoguard from 19E. CWs change every 5-6 seconds. Even though it is CSA, the CW checksums are wrong. The file properly decrypts using the CWs with the wrong checksums. If the checksums are corrected, it doesn't decrypt.
It's for sure CSA and it's allowed to use all 64bit in the key without the checksum.
This rules out RBT, CUDAbiss and many other CW finder programs and makes the searchtime way longer = no realistic for now :(
 

boyet05

Registered
Messages
245
I have also tried this method of recording .ts file and I can get crypt8 and key out of CSA rainbow but it will never wwork I think and this is the message from oscam log.

Card [videoguard2] use k1(DES) for CW decryption in unique pairing mode.

DES key is needed and not CSA.
 

K2TSET

Registered
Messages
125
I have also tried this method of recording .ts file and I can get crypt8 and key out of CSA rainbow but it will never wwork I think and this is the message from oscam log.

Card [videoguard2] use k1(DES) for CW decryption in unique pairing mode.

DES key is needed and not CSA.
The data send to the card over air does use DES or other encryption depending on encryption system.
Then the card decode the ECM to a 64bit CW which is send to the CSA DVB algo to decode the ts in real time.

Try to put in F4652D98B7C624B1 in VLC under advanced preference demux/mpeg-ts/CSA key + second CSA key and play the ts posted above and you have clean picture.

Most of all encrypted DVB on sat / or terrestrial does use CSA as the underlying ts decoding 48+CRC / 64 bit

The 48 bit is a restriction from back time when CSA original was released due to export rules.

The thing with RBT is it only made for 48bit+CRC if you should make it for 64 bit if should be 65.536 times bigger tables
Also next problem is that the stuffing are removed on more and more ts which roles out RBT in the future
 

kebien

Registered
Messages
1,329
Ok,now we are talking.
Most 99% of the services using CSA only need a key 48 bits,which is the grounds for ALL the key searching tools we are currently using.
This is the only reason we can find keys in a reasonable time with the processing power we have today.

Now,is way different to brute force 64 bits,and I am surprised they are using all bits of the key for this sevice.

So,basically,we are dealing with exponentially bigger search times,and CSA has not changed,is not CSA 2 oe 3 or whatever,is just using al available bits of the key for data.

So,the question I am obligated to make is how did this CW were found,since original poster said RBT was/can not be used.

For the layout described in the post,it doesn't show the even and odd CW in the same line.I have never seen an ECM that does not carry both at the same time,so this leave out ECM decryption.
So if this was brute force,how long it took to find them,and of course what method was used.
Pretty new and cool stuff.
 
Last edited:

Psilos2003

Registered
Messages
52
For tsdec_gui the source code is available and the lines that correct the checksums in tsdec.c can be commented out to make it work.
 

kebien

Registered
Messages
1,329
likely ECM decryption by official card.
brute force would take way to long.
Unless they edited the CW line,I know of no ECM that can carry only odd or even CW,but both are always sent to the CA device.
But I see no other way than using an original card to get them.
Maybe they logged the IRD's ram and they show up like this there.
Who knows.
 

kebien

Registered
Messages
1,329
If CW grabbed from real card then I guess they are not using CI+ CAM

You could even log using an adapter,have couple of those from the old days.And CI modules too.
The problem would be if the CI module use no card at all.
Unless you meant exactly that situation,with my apologies
 
Last edited:

K2TSET

Registered
Messages
125
You could even log using an adapter,have couple of those from the old days.And CI modules too.
The problem would be if the CI module use no card at all.
Unless you meant exactly that situation,with my apologies
With CI+ I was refering to encrypted data between card and cam, so when op have the CW I assume not CI+ but normal CI, it CW comes from logging traffic between card and cam
 

kebien

Registered
Messages
1,329
Ok,you mean the CW are not plaintext in a CI+ platform,I understand.
Like Dish receivers do.
Is it that now CI modules are more secure than before?
I remember most all CI modules were dumped,from the first one where CSA algorithm was known and was possible to emulate it in software (freedec).
I imagine someone with the right tools could have done it for videoguard module or ird.
Anyway,thanks for clarifying,was not aware of CI+ was the term used for it.
 

kebien

Registered
Messages
1,329
In the links you provided it show they are using 3 different cards versions.
Maybe IRD pairing algorithm is known for the older card?
But yes,that is also my question from the beginning.
How did this CW were found?
 
Top