342 replies to this topic

[littlesat]

The tar file gets a removed by WanWizard if posted to the forum.

These sources were removed due to it contained a "stolen" CI+ license...

[adri]

At least PLi tries to stay within the legal limits. Contrary to e.g. VTi, who's images are 100% illegal.....

 

Staying within the legal limits for CI+ support means you have to implement the support, then submit your solution to the consortium for approval.

After approval, you will receive the legal certificates.

The approval seems to cost about €15000,- per receiver plus an annual fee.

And we all know, Open source linux receiver will have big problems confirming to the CI+ requirements to get approval.

 

Pick your poison?

[WanWizard]

There is, as always, a grey area.

 

We can implement the support, and leave it at that. If you, as a user, want to submit the solution, fine. If you, as a user, want to steal borrow someone elses certificate and use it, entirely up to you. 

 

We provide the hammer, whether or not you use it to kill someone, is not our problem. There is nothing illegal about selling hammers...

[SpaceRat]

That reminds me of "For someone who only has a hammer in his toolbox, every problem looks like a nail." ...

[WanWizard]

Yup, very true. But not applicable in this case.

[adri]

There is, as always, a grey area.

 

We can implement the support, and leave it at that. If you, as a user, want to submit the solution, fine. If you, as a user, want to steal borrow someone elses certificate and use it, entirely up to you. 

 

We provide the hammer, whether or not you use it to kill someone, is not our problem. There is nothing illegal about selling hammers...

So all the necessary code and/or sources are already available from other implementations.

All you need to do is remove the embedded certificates and provide a means to supply them as an external resource.

But following this discussion, i get the impression even a relatively simple task like that isn't acceptable.

Edited by adri, 11 April 2017 - 17:21.

[WanWizard]

The problem with the current code is that is is manufacturer specific, so that doesn't help much.

 

Not only needs the embedded certificate be removed and a config file solution implemented, but also the code has to be made generic so it can support all manufaturers. Which is what our CI+ API does (it only needs the specific driver API for all manufacturers implemented, which need to be reverse engineered if the code for that manufacturer is not public).

 

So you get: your CI+ module -> CI+ "cam" -> Enigma CI+ API -> hardware abstraction -> hardware drivers.

 

Oh, and it needs someone with the time, will and C++ knowledge to do it. Which isn't me, my last compile of a C program was 30 years ago, using Turbo C.

[Dimitrij]

 

So you get: your CI+ module -> CI+ "cam" -> Enigma CI+ API -> hardware abstraction -> hardware drivers.

This will never happen.

[WanWizard]

And why not?

 

The work is already 80% or 90% done, the existing code needs to be changed to make it a generic cam-type binary (i.e. don't talk directly to the drivers, but talk to the Enigma API that is already finished), and the IO controls for currently non-supported hardware (DMM, VU+, etc) need to be added.

 

Not that much work for someone with a bit of coding experience.

[Lost in Space]

Maybe we should simply listen when babsy98 says which vendors are just using a simple ioctl as DMM does to tell the encoder that they pass an AES encrypted pid (and tracing the ioctl number they use is a 10 min job even if the code is non-public and they don't use the 137 as DMM does).

 

I'm pretty sue that when HE makes such a statement he is not talking nonsense. But I'm repeating myself ...

 

What is more (off course only intellectually) interesting is why VU does it different and how ...

Edited by gutemine, 11 April 2017 - 18:31.

[babsy98]

this is allready done only 3 vendors use different solution all other use same way as dm

[betacentauri]

I can only say that the dream code(the one in the tar file which was attached here in the thread) don't work on a et8500. It's not the iotcl. It's I guess a driver bug. One of the poll calls don't work. The driver don't tell the software that it wants more data(epollout).
Fixing it is not very difficult, but you see that it might need more workarounds for different manufacturers...
(E2 with patch don't have this problem as e2 only uses poll if there is a queue with data).

[Lost in Space]

That's why I said take the missing res_*.c and forget about your great ci plus message interface and you will be done in a few hours ...

 

The dreamciplus code is just using his own main loop and epoll because their core is closed, so there is no other way to do it for them.

 

But as babsy98 said then you have a working solution for 80% of the manufacturers ...

 

I spend weeks to build AutoPin Plugin to overcome all the inherent limitations that it causes ... 

 

The only interesting piece is the res_content_ctrl.c which can build the cert chain and using it when asked, and this reads nicely external certificate files too.

Edited by gutemine, 11 April 2017 - 19:38.

[athoik]

@babsy98, The solution you are mentioning is not public yet! No enigma2 team published that code, why?

Solution 1. Vu+ using streamguru ciplus stack!!!, private, E2 changes

Solution 2. GB using binary helper, no E2 changes

Solution 3. Mut@nt using binary helper, two flavors, one requires the E2 helper interface, the other, newer, no E2 changes

Solution 4. Dream CI Plus, public (requires registration in a forum), no E2 changes, only some python for more that one slot.

Solution 5. Duckbox Developers libdvbci, based on 4, public in github, E2 changes

Solution 6. Universal CI+, based on 4, private patch, E2 changes

Solution 7. Linux CI+ (non STB), uses openssl, based on 4, private, non E2 solution


Seems dream ci plus inspired several people to create a solution using that code.

I really wonder what SW uses the solution 7, vdr? tvheadend? minisatip?

Edited by athoik, 11 April 2017 - 19:53.

[Lost in Space]

ask the developer - he asked in NN2 board where the sources are if I remember correctly  ...

 

the dreamciplus sources compiles nicely on an Intel PC, so if you add the aes in software decryption as suggested further up in the thread you can easily get a working solution there too ... as CPU power is no issue on a PC ...

 

To be honest I think even the dream solution is based on the libdvbci code from Duckbox git, because despite switching from C++ to C, the interrestinmg pice of the sources is almost 98% identical, hence it is also pretty simple to switch them back to C++ They even replicated some bugs from there.

Edited by gutemine, 11 April 2017 - 19:56.

[athoik]

Also seen that code: https://github.com/j...vb/libci/ciplus

Seems like an early development, but has many interesting comments!

[Lost in Space]

Look I only had to read the ugly code from dreamciplus to see how the authentification and MMI interface works, so that I could enable e2 to handle such virtual modules via AutoPin Plugin  (because the ci interface is completely removed from e2 and only recently there was a fake fifo device added to make e2 directly aware of the module name, which made parts of AutoPin obsolete on Open* Images).

 

I will NOT start reading and comparing even more code, as nobody is listening and for me it has no added value.

 

I only spent some more time when the camd socket interface was added to the dreamciplus solution (for whatever reason) and suddenly the dreamciplus also worked on Open* Images, then I was so kind to make AutoPin work on Open* Images, only to find out that your socket interface is outdated and not able to handle multiple connections which produced even more workarounds. because there was no willingness to fix that either

Edited by gutemine, 11 April 2017 - 20:20.

[athoik]

I tried to fix socket interface once.. https://github.com/O...nigma2/pull/438

Anyway you are the only to understand that code, but all the others cannot understand you. What a strange situation

Edited by athoik, 11 April 2017 - 20:26.

[Lost in Space]

Regarding the SocketMMI.py OpenATV was so kind to check into their git my suggested compatibility changes with the optional slot=0 parameter to be at least API compatible on the python side. But this still doesn't solve the problem that internally the old socketmmi.so that you use supports only one connection ... but this is another story ...

 

I didn't say that only I understand the code, but at least I have looked into it - some comments here are simply proving the opposite - like embedded certificates, or binary blob, etc.

 

You added the ciplus message interface already so that some closed source helpers on some boxes are able to work with you image, which is understandable, but if you want a complete and comprehensive solution this is a strange way to hope that now somebody will create an open source helper implementation for this one.

 

But we are circling here the building instead of entering it. Most of the good meant advice was already given by myself and others ... you can now act .... or wait for others ...

Edited by gutemine, 11 April 2017 - 21:30.

[SpaceRat]

Regarding the SocketMMI.py OpenATV was so kind to check into their git my suggested compatibility changes with the optional slot=0 parameter to be at least API compatible on the python side. But this still doesn't solve the problem that internally the old socketmmi.so that you use supports only one connection ... but this is another story ...

What would we need to change?