152 replies to this topic

[theparasol]

I do not agree, since the certificate that is still valid will expire in 2060. That suggests the used certificate tool can handle dates beyond 2049

 

Even the CI+ module itself says expired!

Edited by theparasol, 5 January 2016 - 18:37.

[WanWizard]

This is what the issuer of CI certificates writes in his FAQ.

[Lost in Space]

I'm pretty sure that the certificate chain is a valid one, as almost all boxes use the same certificates and it works nicely with original DMM Images. Even OpenATV uses the same ones.

 

But x-checking assumptions is a hard job, I know ...

 

PS: you are not using the latest public sources either.

Edited by gutemine, 5 January 2016 - 21:05.

[theparasol]

PS: you are not using the latest public sources either.

 

Could be, another fellow openpli forum member delivered them to me

 

But they are not that old either and they are a lot younger than my HD+ CI+ module so for a proof of concept it should be sufficient.

 

However I did download the "dream-ci-plus_2.0-r6_dm7020hd.ipk" from NN feeds (in order to get my hands on some other hopefully valid certificates)

But same certificates in them -> time for another approach!

 

Looking at the code: those certificates are only used if no file exists in /etc/enigma2/ci_auth_%CINAME%.bin

In such files the authenticated data (HostID & DHSK & AKH) is stored for each specific kind of CI module once the certificate check is done and was valided by the CI module.

Next time the certificates are not used for the authentication challenge but the stored authentication data is used instead, it takes pretty long to do so and most of us are impatient

 

Can it be that some images come equipped with such files by default?

[Lost in Space]

If you diff the certificates with the ones ATV delivers you will see that they are identical and they work. Guess how MY HD+ Card and Module are running ...

 

If the Module is 'paired' with the receiver during the CI authentification process the result is stored in the auth files (which are also identical in their structure to what for example ATV produces), you can even copy these authentification file between receivers (and from OpenATV) and then the module will work im both, because the receiver id is created as random number. You are right that after authentification you don't need the certificates anymore until you want to re-authentificate same or authenticate another module.

 

And no the auth file contains the CI Module specific answer and works ONLY with this module (until it is re.authentificated) so shipping these auth file is useless.

 

Check the Libs the working binary is using, your invalid authentification is probably produced by mixing (wrong) versions.

 

PS: You should really try it out first in an Image where it works, before you ask such basic questions ... Then you can use the auth files it produces with your test bed ...  but now you got enough help by an incompetent person ...

 

Ciao

gutemine

Edited by gutemine, 5 January 2016 - 21:53.

[gorski]

Nah, we've been through this: you are generally IT very competent, more competent than most - but let's make some distinctions here, shall we - just sometimes you can't help yourself and then you start talking rubbish by heart...   arrogance embedded...

 

Good reading, this, though...

[theparasol]

In the first place I should try this with a working image to get some confidence that its possible but since I have only one simple receiver and its used in our livingroom that is not an option according to my wife

 

For now forget about the expired certificates I mentioned before, I now assume they do their part of the job just fine!

 

I agree, perhaps the used libs are not the same. I'll do a static link in order to avoid incompatibility issues.

 

So I struggle on:

 

- Latest sources fetched, nothing essential is changed in the authentication challenge code.

 

Reading this topic again from first till last reply something in sockets of enigma need to be changed is mentioned. I have no idea what. Perhaps this is the missing link.

Anyone has any clue what this can be? Is it possible to apply the necessary socket changes in enigma2 sources anyway if they dont introduce any issues?

It would make my testing a whole lot easier.

 

In this case this is not a one man show, I want to contribute my part but if no one is able and willing to help it simply stops!

 

I added the latest untouched sources as nixkoenner provided them on NN2 board (they are dated 3-1-2016)

 

Edited by WanWizard, 8 March 2017 - 15:01.
Attachment removed

[hemertje]

Nah, we've been through this: you are generally IT very competent, more competent than most - but let's make some distinctions here, shall we - just sometimes you can't help yourself and then you start talking rubbish by heart...   arrogance embedded...

 

Good reading, this, though...

 

Gorski,

 

your comments like above isn't helping anyone

 

please let them out of here...

[gorski]

Perhaps you underestimate Gutemine... Perhaps he can understand this, if he applies himself... Perhaps community might benefit from it, should it happen...

 

So, perhaps somebody should say it, after all... And why not me? I am fairly competent in this side of the hobby, if not the IT side...

[betacentauri]

@theparasol: Have you installed the cihelper plugin?

[Dimitrij]

@theparasol:

I want to help.
What to do?

[theparasol]

@theparasol: Have you installed the cihelper plugin?

 

Only enigma2-plugin-extensions-socketmmi, it works fine. Even compared the openpli sources against the one ATV uses an they match up only cosmetic debug output differs a bit.

So my hopes are set on the mentioned needed but still mysterious small "socket" changes in enigma2 sourcecode.

[athoik]

@theparasol: Have you installed the cihelper plugin?

Only enigma2-plugin-extensions-socketmmi, it works fine. Even compared the openpli sources against the one ATV uses an they match up only cosmetic debug output differs a bit.
So my hopes are set on the mentioned needed but still mysterious small "socket" changes in enigma2 sourcecode.

OpenATV uses that plugin only for dreamboxes, right? So maybe someone should check first if this plugin works with OpenPLi+Dreambox and then patch it for other boxes?

[Lost in Space]

Wrong assumptions without checking (as usual, sorry to say this ... again ...)

 

OpenATV uses their public enigma2 code for the handling which is now also in PLi git an a non-bublic helper binary for the authentification part.

 

THIS CI handler is a complete one and also has the authentification part in public code.

 

BUT it is for DMM Original Images with the closed source enigma2 binary  - but as it communicates with enigma2 via a more or less standard socket interface there is NO magic involved ...

[theparasol]

Well whatever magic or no magic is involved, my HD+ CI module doesnt get authenticated in the first place.

At the moment it seems faster to write CAK7 code than to continue this struggle

[Lost in Space]

OK, so you are not reading what I write ...

 

Flash an OpenATV, install their helper, let the module finish authentification, then get the aut*.bin and it will be also authentificated by dream_ci_plus binary in an OpenPLI if you put the file at the right places with correct name /etc/enigma2/ci_auth_HD+_CI_Plus_Modul_0.bin

 

Or you get a Dreamvox 7080 or 7020hd and use it for completing Authentification with this helper.

 

But in both cases you will be back to your socket going into nowhere land problem ...

 

BTW the binary has a -debug 10 option which will tell you lot's of useful output to find out what goes wrong ...

Edited by gutemine, 6 January 2016 - 18:20.

[malakudi]

I wonder why CI+ group hasn't revoked those leaked certificates yet.

[theparasol]

I'm reading what you write alright. But flashing openATV on my only receiver wont gonna happen. Buying any kind of dreambox neither.

Unlike some here I don't have boxes stockpiled, even my knowledge about coding and crosscompiling is very limited.

So on my side it is "limitations, limitations, limitations".

 

Perhaps someone else who knows what he/she is doing manages to get this thing working in whole.

[Lost in Space]

The 'thing' is working as it is since almost 1 year now.

 

When 'they' would revoke a leaked certifficate the original vendor will complain and ask for a new one and the circle would close ...

 

But you see, now OpenSource works perfecly - lack of understanding, testing, infrastructure, patience, advice ... welcome to reality!

 

Complaining about closed sources and drivers is ... easier ... off course.

Edited by gutemine, 6 January 2016 - 18:53.

[theparasol]

But you see, now OpenSource works perfecly - lack of understanding, testing, infrastructure, patience, advice ... welcome to reality!

 

May I remind you I'm just a hobbyist and not an experienced coder in any way: I can merely test and code a little, if it works: fine!, if not I hope someone else can complement my lack of knowledge. I think thats the way opensource should work. On our own we know some things, with joined knowledge of many we know more and can make things work.

Edited by theparasol, 6 January 2016 - 19:03.