Re: Slow zap for CI #81
Re: Slow zap for CI #82
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.
Re: Slow zap for CI #83
Posted 27 February 2016 - 18:50
But it works in - for instance - OpenATV, I heard...???
Re: Slow zap for CI #84
Re: Slow zap for CI #85
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:
Edited by gutemine, 28 February 2016 - 12:56.
Re: Slow zap for CI #86
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.
Re: Slow zap for CI #87
Re: Slow zap for CI #88
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
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916
Re: Slow zap for CI #89
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
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
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.
Re: Slow zap for CI #92
Posted 29 February 2016 - 22:11
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.
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916
Re: Slow zap for CI #93
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
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 #96
Posted 2 April 2016 - 19:54
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.
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916
Re: Slow zap for CI #97
Re: Slow zap for CI #98
Re: Slow zap for CI #99
Re: Slow zap for CI #100
Also tagged with one or more of these keywords: plugin
Missing Softcams PluginStarted by MifPT, 12 Jan 2024 softcams, Plugin and 1 more... |
|
|||
openpli 9 and Xtream pluginStarted by frossie, 10 Dec 2023 plugin |
|
|||
Advanced transcoding setupStarted by Dimitrij, 14 May 2022 plugin |
|
|||
Plugin - Power LNB/ToneBurst in standby for FBC tunersStarted by Dimitrij, 6 Apr 2022 plugin |
|
|||
imdb plugin
IMDB plugin issuesStarted by scriptmelvin †, 1 Jun 2021 imdb plugin, imdb, plugin |
|
2 user(s) are reading this topic
0 members, 2 guests, 0 anonymous users