342 replies to this topic

[WanWizard]

It is lacking in any image. And it wil never be supported directly by any image, for the same reason an emu or a softcam + keys is never part of an image: it is highly illegal.

 

The binary blobs that some images included, and was available for download in OpenPLi for a short period of time, has been removed for exactly that reason, as the CI plus Consortium has already threatened with legal action.

 

So another solution has to be found, which is not that simple.

[Erik Slagter]

Cl+ support Is needed. And in OpenPLI notably. Very lacking this functional.

A whole pile of money on my account is also "needed". It's all relative. And certainly not the proper way to ask support.

[Lost in Space]

Well, ... the Dreambox helper runs nicely together with OpenPLi on dm7020hd, dm7080, dm525 and dm900, as it does with all the other Open* and DreamOS Images ... which has some amusement value ... because their solution is completely Open Source ...

 

So either help yourself ... or stop moaning ...

Edited by gutemine, 14 March 2017 - 19:14.

[theparasol]

We tried to get this working but it need something more. The opensource part on its own is just not enough to get it running!

The CI driver part of the dreambox series have them, other manufacturers obviously not (yet)

So there is no question why this ci+ helper solution construction exists and who invented it.

Still a valid CI+ certificate is needed and there is just no legal way to obtain and spread it. User has to add it themself.

 

I'm hoping someone invents a new way that outsmarts the Dreambox solution

[Lost in Space]

Come on - the only missing piece you found at that time was an ioctl argument - reverse engineering this part takes strace and < 1h effort.

 

Even I could be able to do that ... but it would probably take me 1 day ....

 

So there is nothing to outsmart ... except your argument ... and maybe the pride of the VTi team ...

 

And the users already have added already lots of cookies to their milk ... themselves ...

Edited by gutemine, 14 March 2017 - 19:55.

[zeros]

Is this thread?
https://forums.openp...ugendschutzpin/
Which still need to pay attention and what is the latest version, what to try?

[Lost in Space]

No, the lastest public sources I think are Version 7.x and you can find them in NN2 board. There is also a deb und ipk kit for mipsel and armhf and they work nicely on all mentioned Dreamboxes.

Edited by gutemine, 14 March 2017 - 20:26.

[adri]

And if other manufacturers care to examine the open source, they can quickly see what ioctl support they have to add to their drivers......

So I guess it all depends on VU and other to update their drivers.

Doing so is not illegal, but afterwards allows them to support CI+ using the DMM open source solution.

[Lost in Space]

This is NOT "a DMM open source" solution it is a working solution for Dreamboxes available since 3 years.

 

But again do you really think that these non shared libs linked to the enigma2 binaries or helpers have any "Hidden Additive" inside ???

 

The chance that the vendors just added a random ioct number or maybe a wrapper call for sending aes encytped pids to their demux is in the 90+% range because it is allways the same Broadcom Chips. Finding out these ... when you can watch a working binary is really a pretty simple and straight forward task.

 

Instead the entire community is now begging and mourning in all Open* forums to come up with a solution .... and "expert programmers" blame vendors and drivers and chip manufacturers (and want to force them to re-implement what was done long ago but probably simply not shared with everybody), instead of just putting the last and obvious puzzle piece into place ...  which brings me back to having some amusement value ...

 

But as already stated multiply here ... I'm just a dumb person ... always pretending to know better ....

Edited by gutemine, 14 March 2017 - 21:25.

[WanWizard]

All solutions to make a CI+ module work contain an X.509 certificate issued by the CI plus consortium.

 

This certificate is ONLY issued to manufacturers, and ONLY for a specific device, which needs to be certified by the consortium, and which has to work 100% according to the CI+ specifications. For this reason, NO open source device will EVER receive such a certificate. All CI+ code "out there" either only enables the CI+ in standard CI mode (which works as long as the provider doesn't enable the plus functionality on the smartcard), or contains a certificate, either stolen from another device, or assigned to another device from the manufacturer, and re-used for their Linux devices.

 

This last point is the reason the image builders have removed the CI helper solutions, because those manufacturers have received a court order from the CI+ consortium.

 

So another solution is needed, one that isn't illegal for both the manufacturer and the image builder, but still gives the end-user the possibility to get the module to work. Compare it with using a softcam and EMU keys. This will happen, but it won't be happening overnight, as there are a lot of parties that have to work together. We managed to do this in the past with the standard softcam interface, and we are confident we can do it again with a standard CI+ interface.

[Lost in Space]

Maybe you are praying to the disbelievers, because why are then so many box keys, rsa keys ,... for various "other purposes which I hardly understand" found at various places and compiled into binaries discussed openly here .... and they are also used by Open Source solutions like oscam ....

 

I'm pretty sure that these pieces of information were not posted by the manufacturers intentionally either

 

Don't get me wrong, I will NOT support any illegal activity like stealing certitficates,... But finding out with strace or gdb the unknown argument to an ioctl command is not even close to that. BTW you can even remove these illegaly obtianed certificates after the pairing of the module and it will still work after the trust chain was establised and verified by the device.

 

Otherwise if we go to the other extreme ... you would not even be allowed to build something like libcss for your images ...

 

The solution for the Dreambox uses only the camd socket - so it is even cleaner than your weird ciplus helper socket solution from your git.

Edited by gutemine, 14 March 2017 - 22:34.

[theparasol]

Its rather sad to see these days that buying a valid subscription and additional ci hardware to watch certain channels you can still be forced by law to use a provider approved receiver: We all know those receivers don't work perfect and contain all kinds of bugs and restrictions!

 

I dont want to be pessimistic:

 

I suspect in case we find a perfect solution so ci+ modules can be used legally the content providers will enforce some new rule that their content wont be delivered to a provider unless they agree to implement a cardless encryption system. The classic "card" will be moved into the soc of the receiver.

I presume that means game over for the enigma enthusiast and all dreambox and spinoff receivers of the last 15 years.

[MastaG]

I can find myself in WanWizard's post here.

A bit offtopic, but I understand why they're taking legal actions against these CI+ solutions in 'open'-platforms such as e2 receivers.

 

Last week my employer sent me to the US to do a training over at google to implement their drm solution called widevine.

Their widevine drm system is used for protecting http-based streams (ott) for android, ios and html5-based players.

The demands from the content-owners and studios are getting more strict and they become more aware of the piracy risks these days.

So the google widevine team is working closely with chip-vendors to obtain level 1 security, which basically means the video is being decrypted in a secure trustzone area of the SoC and there's a secure path from that zone to the hardware a/v-decoder.

For example web browser-based players (html5 with mse/eme) do not offer level 1 encryption yet (with the exception of ms edge on windows 10 using the latest intel gpu's), which means they're using a software-based drm library/plugin (level 3 security), which is of course much weaker.

And many (if not most) content-owners and studios are aware of that so they restrict their content only to be served in sd-quality when there's no hardware solution available, like SkyUK for example.

[littlesat]

Just my 2 cents....

 

Due to legal aspects I think that CI+ support could only be done via 'binary helpers' that come from vague undefined sources... (compare it with the so called PAU plugin that allows recordings on 'some' receiver(s))...

We have already a CI+ implementation available. I think we do not need to have multiple systems in place.

For every manufacturer that 'wants' CI+ support on OpenPLi should arrange somehow a 'binary helper from a vague undefined source' that is compatible on the interface we now have -or- we may define as there exists a real improvement.

Edited by littlesat, 15 March 2017 - 09:46.

[Dimitrij]

Just my 2 cents....

 

Due to legal aspects I think that CI+ support could only be done via 'binary helpers' that come from vague undefined sources... (compare it with the so called PAU plugin that allows recordings on 'some' receiver(s))...

We have already a CI+ implementation available. I think we do not need to have multiple systems in place.

For every manufacturer that 'wants' CI+ support on OpenPLi should arrange somehow a 'binary helper from a vague undefined source' that is compatible on the interface we now have -or- we may define as there exists a real improvement.

Let's be realistic.
This means that there will never be a support CI+ on openPli for all recievers.

[littlesat]

Why is this not realistic?

 

Basically we 'only' need to convince VU for this principle and ET and we're in business...

 

Accepting different solutions based on the 'force' of all manufacturers it the thing that should be a no-go or not-done.... The issue here is that other teams simply adapt to this 'crap'... They did accept the multiple CI solution 'crap'...

 

As result the manufacturers can do what they want... (shortly not really supporting the OpenSource idea and only gathering money with doing the minimal effort)...

 

But somehow all of this is starting to get 'out of scope'.... as finally it seems the whole CI+ was doubt full and withdrawn by the same manufacturers...

 

But at the end it sounds like having CI+ support has priority to how CI+ support is implemented.... And then the extra aspect.... It is not genuine/legal at all....

Edited by littlesat, 15 March 2017 - 11:43.

[Dimitrij]

My personal opinion...
I absolutely do not care about the manufacturers of receivers.

Support for CI+ is the prestige of the image.

If I can do anything, I always try to do it myself.

Unfortunately, my knowledge is not enough.

[WanWizard]

I do not agree with Littlesat, as I explained above.

 

The only thing that makes it illegal, is the CI+ certificate. For everything else, a "ci+cam" can be make in software, which will use the standard ciplus interface of Enigma. It is then up to the user to find a certificate. The same way is true if you install Oscam, and you want to use keys or a smartcard that requires an RSA key.

 

So there is no need for a ci-helper to be binary (the only reason it is binary is to obscure the presence of that certificate), and there is also no more need for vendor specific ci-helpers.

 

It will also relieve the vendors from coming up with a solution for this, which can possibily link their name to an illegal activity.

[littlesat]

But are you sure it's only the license that is not done here?

[WanWizard]

The license of what?

 

The certificate used is licensed to a specific manufacturer, for a specific device, and issued after succesful certification of the hardware. The license explictly forbids the manufacturer to use the certificate on other devices.

 

There is no license involved in the code, as that code still has to be written. The manufacturer needs to provide support in the drivers, and supply us with the API (ioctls) to use. We can then export a generic interface (which we already have for the manufacturers that already have provided us with that API, see https://github.com/O...a9c78058ef57da4), to which an external binary can talk.

 

I personally don't care if that is a generic "Oscam-like" binary that uses external certificate files, of a binary helper from a manufacturer. That's the risk that manufacturer wants to take, we are no party. I prefer the generic binary though, if only because it would provide the same solution for all boxes, instead of vendor specific solutions.