Opened 7 years ago

Closed 4 years ago

#4359 closed defect (fixed)

NDS CWs are dropped when connected to real CCCam servers

Reported by: ua2Ahfieghah Owned by:
Priority: blocker Component: General
Severity: medium Keywords:
Cc: Sensitive: no

Description

Revision

since revision 10005

Issue Description

NDS (e.g. caid 0963, 09C4, 098C) CWs are dropped due to CW half check when
operating as CCCAM client and connected to CCCAM server

When the issue occurs

no picture

How the issue is reproducable

when connected to CCCAM server (I face this issue with every public server available), I am receiving CWs, of following type:

0: XX XX XX XX XX XX XX XX 00 00 00 00 00 00 00 F0
and
1: 00 00 00 00 00 00 00 00 XX XX XX XX XX XX XX XX

the case 0: is currently always rejected by OSCAm as the code expects
that last octet is 00

this is also the case when connected to a OSCAM server operating as CCCAM server

I have already verified (see patch blow), when relaxing the check and accepting in last octet an 0xF0, the channels become "clear".

--- a/oscam-ecm.c
+++ b/oscam-ecm.c
@@ -2637,8 +2637,15 @@ uint8_t checkCWpart(uchar *cw, int8_t part)
 {
        uint8_t eo = part ? 8 : 0;
        int8_t i;
-       for(i = 0; i < 8; i++)
+       for(i = 0; i < 7; i++)
                if(cw[i + eo]) { return 1; }
+       if(part)
+       {
+               if(cw[i+eo] && cw[i+eo] != 0xF0) { return 1; }
+       }
+       else if(cw[i+eo])
+               return 1;
+
        return 0;
 }

The attached log file was created when applying following (for debugging purposes) patch additionally:

--- a/oscam-chk.c
+++ b/oscam-chk.c
@@ -1036,6 +1036,9 @@ int8_t chk_halfCW(ECM_REQUEST *er, uchar *cw)
         int8_t part1 = checkCWpart(cw, 0);
         int8_t part2 = checkCWpart(cw, 1);

+        char tmp[16*3+1];
+        cs_log("er->caid=%04X, cw=%s", er->caid, cs_hexdump(1, cw, 16, tmp, sizeof(tmp)));
+
         //check for correct half cw format
         if(part1 && part2){
                 return 0;

Attachments (1)

oscam.log (25.2 KB ) - added by ua2Ahfieghah 7 years ago.

Download all attachments as: .zip

Change History (12)

by ua2Ahfieghah, 7 years ago

Attachment: oscam.log added

comment:1 by ua2Ahfieghah, 7 years ago

Another way of fixing the problem would be to apply the following patch instead:

--- a/oscam-chk.c
+++ b/oscam-chk.c
@@ -1033,11 +1033,16 @@ int8_t chk_halfCW(ECM_REQUEST *er, uchar *cw)
 {
   if(is_halfCW_er(er) && cw){

+        uchar cw15 = cw[15];
+        if(get_odd_even(er) == 0x80 && cw[15] == 0xF0)
+                cw[15] = 0;
+
         int8_t part1 = checkCWpart(cw, 0);
         int8_t part2 = checkCWpart(cw, 1);

         //check for correct half cw format
         if(part1 && part2){
+                cw[15] = cw15;
                 return 0;
         }

@@ -1051,6 +1056,7 @@ int8_t chk_halfCW(ECM_REQUEST *er, uchar *cw)
                return 1;
         }

+        cw[15] = cw15;
         return 0;  //not correct swapped cw

   }else

This would have the advantage that in case replies from OSCAM server (with CCCAM protocol) and CCCam server are available at the same time, both replies can be used together in a DOUBLE CW check. This place is surely not the perfect place to do this kind of "patching" of the CW reply. Unfortunately I do not know the code that well that I could easily find a better location.

comment:2 by ua2Ahfieghah, 7 years ago

Another reason why the CW should be patched is to be able to reshare the CWs with a OSCAM version which include the half CW check enforcement and which does not yet include the fix. Otherwise such a version would "drop" all those CWs. When the CW is patched on the other hand, only the resharing server must include the fix. This means we would not need to wait for the receiver image to include a newer OSCAM version.

comment:3 by FrancYescO, 7 years ago

Thanks for your patches i'll test.

i already posted this issue in the past but i got ignored, at least seems you got exactly where is the issue.
http://www.streamboard.tv/oscam/ticket/4195

Last edited 7 years ago by FrancYescO (previous) (diff)

comment:4 by ankn76, 7 years ago

I can confirm that the proposed patch on oscam-ecm.c restore the same correct behavior of builds <= 10005. The CWs coming from the CCcam servers I tested are not discharged with this fix. Please, consider its inclusion.

Last edited 7 years ago by ankn76 (previous) (diff)

comment:5 by tom_4242, 7 years ago

I can also confirm the the patch oscam-chk.c is working very well. so maybe it is possible to implement it. maybe it is also possible to enable/disable it via webif so it will not disturb something else - but i did not find anything till now, which is not running with this patch anymore.
I'm also very surprised that this "bug" is not already fixed till version 10006, because not only me is struggleing for a while with this problem and costs a lot of time to test verious oscam versions (I already now the answer - IT IS NOT AN OSCAM BUG...)
maybe some of the developer can reply to this ticket?

by the way - very good job ua2Ahfieghah !!! - well done :-)

Last edited 7 years ago by tom_4242 (previous) (diff)

comment:6 by ankn76, 7 years ago

Is there someone that could explain the origin of this spurious 0xF0 byte at the end of such CWs? Is a kind of anticascading counter-measure or a broken server? I've verified that this spurious value was present with revision 10005 but (for a bug fixed in 10006?) it was ignored (read, not checked).

comment:7 by ua2Ahfieghah, 7 years ago

Actually I cannot explain. I can only say that the CW check for NDS never worked for me with any version with these CCCam servers. Previously (prior revision 10005), the CW check for NDS actively had to be activated. Thus the check was no real issue. Now, on the other hand, this check is enforced and there exists no way to deactivate it. Thus since version 10005, I was not able to use any OSCAM version any longer. With this patch (the one changing oscam-chk.c), I do not face any issue any more but I cannot guarantee that the 0xF0 value will change into another value in the future as noone reading here knows the root cause of the value or at least is not replying. Can we take this patch anyway in and in case the value changes at some point in the future adapt the code further? Would this be an option?

comment:8 by ua2Ahfieghah, 6 years ago

From most recent commit I could see that you are trying to fix oscam working with MCS serers. Actually I do not have any issues as I am using since raising this ticket my patch. You could consider applying this patch as well. Here again the patch for your reference.

--- a/oscam-chk.c
+++ b/oscam-chk.c
@@ -1033,11 +1033,16 @@ int8_t chk_halfCW(ECM_REQUEST *er, uchar *cw)
 {
   if(is_halfCW_er(er) && cw){

+        uchar cw15 = cw[15];
+        if(get_odd_even(er) == 0x80 && cw[15] == 0xF0)
+                cw[15] = 0;
+
         int8_t part1 = checkCWpart(cw, 0);
         int8_t part2 = checkCWpart(cw, 1);

         //check for correct half cw format
         if(part1 && part2){
+                cw[15] = cw15;
                 return 0;
         }

@@ -1051,6 +1056,7 @@ int8_t chk_halfCW(ECM_REQUEST *er, uchar *cw)
                return 1;
         }

+        cw[15] = cw15;
         return 0;  //not correct swapped cw

   }else

comment:9 by zywo, 6 years ago

I can confirm that the patch is working well. Thank you @ua2Ahfieghah

Why after 14 months, the fix is not yet applied ?

comment:10 by Gorgone Impertinence, 6 years ago

Last edited 6 years ago by Gorgone Impertinence (previous) (diff)

comment:11 by Opti, 4 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.