Jump to content


Photo

Slow zap for CI

plugin

  • Please log in to reply
152 replies to this topic

Re: Slow zap for CI #81 Lost in Space

  • Senior Member
  • 876 posts

+69
Good

Posted 21 February 2016 - 16:03

B)



Re: Slow zap for CI #82 betacentauri

  • PLi® Core member
  • 7,185 posts

+323
Excellent

Posted 27 February 2016 - 18:31

Authentification works as already said. I also get an image and sound on a et8500 but only for 1-3 seconds. Then picture becomes black and sound stops.

 

I'm quite sure that this code cannot work:

struct ca_descr_s d;
d.index = index;
d.parity = parity;
memcpy(d.cw, data + (parity * 8), 8);
if (ioctl(desc_fd, CA_SET_DESCR, &d))
	printf("CA_SET_DESCR\n");

And this too as only dream has implemented the ioctl

d.index = index;
d.parity = parity;
d.data_type = CA_DATA_KEY;
d.length = 16;
d.data = data;

if (ioctl(desc_fd, CA_SET_DESCR_DATA, &d))
	printf("CA_SET_DESCR_DATA\n");

Problem is that the data between CI and box is encrypted with AES128. The box needs to decrypt it.

With the CA_SET_DESCR you normally set the decryption key. But with it you can only set a CSA key not a AES key. CSA keys are 8 bytes long. In this case here we have AES encryption with 16 bytes key and 16 bytes initialization vector. So the ioctl(CA_SET_DESCR) cannot work as you can only transfer 8 bytes to the driver.

So we need a way to tell the chipset that it should use AES decrambler with a specific key and iv. I see no way to do it without something like CA_SET_DESCR_DATA. But the manufacturers have to implement that.


Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04

Re: Slow zap for CI #83 gorski

  • Senior Member
  • 1,699 posts

+46
Good

Posted 27 February 2016 - 18:50

But it works in - for instance - OpenATV, I heard...???


<span style='font-family: comic sans ms,cursive'>"Enlightenment is man's emergence from his self-incurred immaturity. Immaturity is the inability to use one's own understanding without the guidance of another. This immaturity is self-incurred if its cause is not lack of understanding, but lack of resolution and courage to use it without the guidance of another. The motto of enlightenment is therefore: Sapere aude! Have courage to use your own understanding!</span><br /> <br /><span style='font-family: comic sans ms,cursive'>Laziness and cowardice are the reasons why such a large proportion of men, even when nature has long emancipated them from alien guidance..." I. Kant, "Political writings" (1784)</span><br /> <br /><span style='font-family: comic sans ms,cursive'><a class='bbc_url' href='<a class='bbc_url' href='http://eserver.org/p...lightenment.txt'>http://eserver.org/p...ent.txt</a>'><a class='bbc_url' href='http://www.english.upenn.edu/~mgamer/Etexts/kant.html</a>'>http://www.english.upenn.edu/~mgamer/Etexts/kant.html</a></a> - the jolly text on Enlightenment, at the basis of Modernity...</span>

Re: Slow zap for CI #84 betacentauri

  • PLi® Core member
  • 7,185 posts

+323
Excellent

Posted 27 February 2016 - 20:36

Not this version. The manufacturers have adapted the drivers and/or have delivered special libraries.


Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04

Re: Slow zap for CI #85 Lost in Space

  • Senior Member
  • 876 posts

+69
Good

Posted 28 February 2016 - 12:52

No, if you compile the binary on a Dreambox with the OLD code and run it you will get the same behaviour - decryption for 1-2 secs and then it stops.

 

So the code can not be completly wrong in my understanding, as it only passed keys to the Module and this uses it to do something.

 

And this code piece appeared in the sourcces only after the discussion started here .... so I would assume it is more as a kind of hint and not a solution, as it would allow to run these sources also on older dreamboxes which didn't have the ioctl 137 in their drivers either.

 

from ca.h you can see that:

 

#define CA_SET_DESCR      _IOW('o', 134, ca_descr_t)
 
I would check where and how this code is used in your enigma2 sources and compare how to fill the ca_descr_t then it will probably work ... but I already said too often that you should stop blaming drivers and look at what you have and know instead of complaining ....
 
Ciao
gutemine

Edited by gutemine, 28 February 2016 - 12:56.


Re: Slow zap for CI #86 betacentauri

  • PLi® Core member
  • 7,185 posts

+323
Excellent

Posted 28 February 2016 - 21:44

 

No, if you compile the binary on a Dreambox with the OLD code and run it you will get the same behaviour - decryption for 1-2 secs and then it stops.

 

Good to know.

 

 

So the code can not be completly wrong in my understanding, as it only passed keys to the Module and this uses it to do something.

 

That's afaik wrong. The key is not passed to the module with the CA_SET_DESCR_DATA ioctl command. It is passed to the drivers which then configure the descrambler in the box so that the box can decrypt the data from the CI module.

Again: The CI+ module decrypts the CSA encrypted TS stream. Afterwards it encrypts the data again with AES and sends it to the box. I guess it only encrypts the data after a few seconds. That's why I can see video/audio for a few seconds. The box then needs to decrypt the AES data (see CI+ spec).

 

Unfortunately the drivers are closed source. Whether they can handle AES keys we don't know. If they can handle them somebody needs to tell us how. The CA_SET_DESCR and CA_SET_DESCR_DATA with 137 or 134 are not working here. That CA_SET_DESCR is not working is logically as it can only handle 8 bytes keys.

 

I already have checked E2 sources. CA_SET_DESCR is not used! I guess only softcams use it.

 

@theparasol: I think you have much more knowledge about softcams than me. What kind of keys does oscam set with CA_SET_DESCR? Only CSA keys? Are there any cases where oscam handles DES, AES encrypted TS streams?


Edited by betacentauri, 28 February 2016 - 21:45.

Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04

Re: Slow zap for CI #87 adri

  • Senior Member
  • 373 posts

+5
Neutral

Posted 28 February 2016 - 22:15

Betacentauri,

 

Oscam on newer dramboxes can handle PowerVU DES encrypted streams in hardware.

This seems to be using the new extended_cw functions of the drivers.



Re: Slow zap for CI #88 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 28 February 2016 - 22:58

Oscam on newer dramboxes can handle PowerVU DES encrypted streams in hardware.
This seems to be using the new extended_cw functions of the drivers.


They name it extended_cw, but actually it is CA_SET_DESCR_DATA and it works only on Dreamboxes (and maybe fulan/spark).

It is mentioned almost since the start of this thread: http://forums.openpl...e-2#entry522226
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Slow zap for CI #89 adri

  • Senior Member
  • 373 posts

+5
Neutral

Posted 29 February 2016 - 11:18

They name it extended_cw, but actually it is CA_SET_DESCR_DATA and it works only on Dreamboxes (and maybe fulan/spark).


It is mentioned almost since the start of this thread: http://forums.openpl...e-2#entry522226

 

 

I know about the CA_SEt_DESCR_DATA, but I just wanted to point out, that as far as I'm aware, this is only used by oscam to switch between CSA, DES or AES encrypted streams.

The type of stream encryption is probably read from the pmt info.

 

And currently there is a bug in the oscam code for setting CSA encryption, so after watching a DES or AES stream, the screen stays black for all subsequent CSA streams, until a reboot.



Re: Slow zap for CI #90 Lost in Space

  • Senior Member
  • 876 posts

+69
Good

Posted 29 February 2016 - 20:34

Instead of doing assumptions you should look at a driver example which actually implements both ways to understand the difference ...

 

https://github.com/D...tm/dvb/dvb_ca.c

 

Is always an inspiration worth ...

 

And don't forget that you kicked out Dreamboxes from your development just because they decided to use different arguments to their drivers ... but you are good in forgetting ... which I know already ...


Edited by gutemine, 29 February 2016 - 20:37.


Re: Slow zap for CI #91 betacentauri

  • PLi® Core member
  • 7,185 posts

+323
Excellent

Posted 29 February 2016 - 21:37

You're also doing assumptions ;)

 

I know it's possible with a broadcom sdk. But I don't have one as I guess everybody here. And perhaps there is a way with the current drivers, but I didn't found one yet. I already did a strace on OpenATV e2 but nothing is visible.

 

 

Please don't start arguing with me about dreamboxes. I haven't made the decision! And yes, dream did this time a good job in implementing this ioctl.


Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04

Re: Slow zap for CI #92 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 29 February 2016 - 22:11

Actually DMM has that long, long time ago...

Even the old dm800 (yes last drivers date back to 2013) has hardware acceleration for DES and people from oscam used that in order to descramble pvu without stream relay.

I said since the start of this thread, that CA_SET_DESCR_DATA, ATM is Dreambox specific.

I got back from @gutemine:


Please look carefully and stop posting nonsense. This Feature is just for setting the CA Data, changing this piece of code according to what you use in YOUR enigma2 code for other boxes to do the same task takes 10 min of cut & paste.

This is a complete CI handler in a standalone binary fed via a socket, it even works without the cI+ garbage if you want it that way.

If you want to annoy me you are pretty efficient ...


Really, nonsence? We can change in 10 minutes closed source drivers? and with cut & paste code?

I think we need stop this madness here...

Edited by athoik, 29 February 2016 - 22:11.

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Slow zap for CI #93 malakudi

  • Senior Member
  • 1,449 posts

+69
Good

Posted 29 February 2016 - 22:21

Generally speaking, descrambling AES stream of about 60Mbit can easily be done in software, at least on the newer boxes. My VU+ Duo2 does 20MB/sec on AES-128-CBC (that is 160 Mbit/sec - much higher than the traffic of CI) and 15 MB/sec on AES-256-CBC. So, if the data from CI to hardware demuxer can be "captured" in some place, AES decrypt could be done with software.

 

edit: OpenATV and other images on VU+ just use a statically linked library. So no new driver needed, at least for VU+. We just need to find what this statically linked library does. It could be using a different IOCTL from DMM for example. Or it could be using a direct functionality update on the driver/hardware, like pau utility does.


Edited by malakudi, 29 February 2016 - 22:27.


Re: Slow zap for CI #94 Lost in Space

  • Senior Member
  • 876 posts

+69
Good

Posted 29 February 2016 - 23:08

Well, if you would check if and what routines the helper binary from OpenATV contains for Dreamboxes and non Dreamboxes ... you would know a little more - a simple strings  and pipe into grep can be very informative already ...

 

And you even cite my hint and insist of not reading it ... amazing ...



Re: Slow zap for CI #95 Dimitrij

  • PLi® Core member
  • 10,381 posts

+354
Excellent

Posted 2 April 2016 - 09:59

athoik

Any news?
I am ready to help with the tests.


GigaBlue UHD Quad 4K /Lunix3-4K/Duo 4K


Re: Slow zap for CI #96 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 2 April 2016 - 19:54

Hi Dimitrij,

Do you have a supported receiver and supported CI+ module/card?

If yes, does it work with Newnigma?

If no, there is no need to spend time on this.
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Slow zap for CI #97 Dimitrij

  • PLi® Core member
  • 10,381 posts

+354
Excellent

Posted 3 April 2016 - 12:49

et8500/Formuler1 not support Newnigma.


GigaBlue UHD Quad 4K /Lunix3-4K/Duo 4K


Re: Slow zap for CI #98 theparasol

  • Senior Member
  • 4,157 posts

+198
Excellent

Posted 3 April 2016 - 15:04

They only have support for dreambox models...


@Camping: ZGemma H.2S, Technisat Multytenne 4-in-1 @Home: Edision Mini 4K, Wave Frontier T55, EMP Centauri EMP DiSEqC 8/1 switch, 4x Inverto Ultra Black single LNB


Re: Slow zap for CI #99 Dimitrij

  • PLi® Core member
  • 10,381 posts

+354
Excellent

Posted 4 April 2016 - 09:02

I have a friend user with  CI+ module/card and dreambox7020hd


GigaBlue UHD Quad 4K /Lunix3-4K/Duo 4K


Re: Slow zap for CI #100 Dimitrij

  • PLi® Core member
  • 10,381 posts

+354
Excellent

Posted 5 January 2020 - 14:33

ver. 1.1


GigaBlue UHD Quad 4K /Lunix3-4K/Duo 4K




Also tagged with one or more of these keywords: plugin

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users