Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#1707 closed defect (fixed)

[PATCH] Most (60%) of Global EMMs gives errors before being written on NDS VG2 Sky Brazil

Reported by: wyrm Owned by:
Priority: major Component: Reader
Severity: medium Keywords: nds, videoguard2, skybr, emm, au
Cc: Sensitive: no

Description

Revision

4803

Issue Description

Most Global EMMs on skybr are not being written to card.
Seems to be because of incomplete EMM support.
On skybr these global EMMs are very common (more than 50% of global emms):

8230 AD 10 0001

C043 02

00
83 9081.....

C010 02

06 02E6.....
16 9081.....

Results in: "emmtype=global, len=173, idx=31, cnt=1: error (0 ms) by sky-1"

The current code can only handle EMMs with "0000" separator. With "0001" separator it fails because of the larger sub-emm length field (6 bits when "0000" vs 14 bits when "0001").

EMMs with "0000" as separator do get written to card, BUT if the EMM has more than one sub-emm only the first one is actually written.

Overall, for skybr, if you have no blocks on EMM-Gs less than 25% of EMM-Gs are actually written. More than 50% give out errors and more than 20% gives no errors but are silently ignored.

There are a lot of other issues with NDS EMM code. Code is very confusing and fails to do proper sanity and boundary checks.

When the issue occurs

EMM Enabled on any service from 0902 caid.

How the issue is reproducable

EMM Enabled on any service from 0902 caid, EMM-G not blocked.

Attachments (2)

vg2_emm.patch (3.8 KB ) - added by wyrm 13 years ago.
vg2 emm fix - version 1
vg2_emm.2.patch (4.5 KB ) - added by wyrm 13 years ago.
vg2 emm fix - version 2

Download all attachments as: .zip

Change History (36)

comment:1 by wyrm, 13 years ago

The following patch fixed all the EMM-G issues on Videoguard2 for me.

It may have issues with clients other than oscam-dvbapi because it expects that emm packets that weren't tampered in any way (e.g. skipping "0000 separator"). Though such clients are probably simply broken because "0000" isn't really just a "separator".

The code looks cleaner to me, and has lots of sanity and boundary checks. It is able to handle EMMs with multiple sub-EMMs, writing all of them to the SC (previous code would always write only one sub).

The current patch applies to videoguard2 only, but shouldn't be hard to change it to videoguard-common. I will do it upon request if somebody is willing to test it on videoguard 1(or 1+).

by wyrm, 13 years ago

Attachment: vg2_emm.patch added

vg2 emm fix - version 1

comment:2 by wyrm, 13 years ago

Summary: Most (60%) of Global EMMs gives errors before being written on NDS VG2 Sky Brazil[PATCH] Most (60%) of Global EMMs gives errors before being written on NDS VG2 Sky Brazil

A few examples of how the patched codes handles some corner case EMMs that the previous code failed in some way:

EMM with 4 subs:

2011/03/15 23:09:39 B5CCA280 c emm:
2011/03/15 23:09:39 B5CCA280 82 30 A5 30 00 00 DF 02 00 3A 90 38 40 03 D4 02
2011/03/15 23:09:39 B5CCA280 D8 37 69 A5 FB D8 96 35 44 42 04 E3 D6 F4 70 A8
2011/03/15 23:09:39 B5CCA280 98 24 CC 91 66 29 47 F2 04 FE 86 74 B6 B5 35 F6
2011/03/15 23:09:39 B5CCA280 3D 7D 2C FA A5 F9 C1 40 06 8D C5 08 A1 43 2A E0
2011/03/15 23:09:39 B5CCA280 47 CD 2B 7A 00 D0 02 06 02 E6 10 11 26 37 16 90
2011/03/15 23:09:39 B5CCA280 14 40 08 B5 58 CA 54 6F 66 78 36 32 FA 72 E4 67
2011/03/15 23:09:39 B5CCA280 A0 48 77 38 BF 00 D0 02 06 02 E6 10 11 2B 3C 16
2011/03/15 23:09:39 B5CCA280 90 14 40 04 B2 D8 A4 B5 52 16 FE E0 5B D5 39 13
2011/03/15 23:09:39 B5CCA280 87 2E 9B 4B 8D 7E 00 D0 02 06 02 E6 10 11 30 41
2011/03/15 23:09:39 B5CCA280 16 90 14 40 03 72 A3 63 EB 89 1F A1 81 5F 08 B5
2011/03/15 23:09:39 B5CCA280 EF 22 6B 27 6C 4D 93 00
2011/03/15 23:09:39 B5CCA280 c emm reader sky-1 has no provider set
2011/03/15 23:09:39 B5CCA280 c EMM: GLOBAL
2011/03/15 23:09:39 B5CCA280 c emmtype global. Reader sky-1 has serial XXXXXXXXXXXXXXXX.
2011/03/15 23:09:39 B5CCA280 c emm UA/SA:
2011/03/15 23:09:39 B5CCA280 00 00 00 00 00 00 00 00
2011/03/15 23:09:39 B5CCA280 c emm is being sent to reader sky-1.
2011/03/15 23:09:39 B74D4B70 r [videoguard2-reader] EMM request return code : 9020
2011/03/15 23:09:39 B74D4B70 r [videoguard2-reader] EMM request return code : 9020
2011/03/15 23:09:39 B74D4B70 r [videoguard2-reader] EMM request return code : 9020
2011/03/15 23:09:39 B74D4B70 r [videoguard2-reader] EMM request return code : 9020
2011/03/15 23:09:39 B74D4B70 r wyrm emmtype=global, len=165, idx=17, cnt=1: written (201 ms) by sky-1

EMM Without SC-EMM:

2011/03/15 23:13:38 B5CCA280 c emm:
2011/03/15 23:13:38 B5CCA280 82 30 68 00 00 00 F2 07 61 01 30 01 FF 5B FF FF
2011/03/15 23:13:38 B5CCA280 FF FF FF FF DD 01 00 02 00 01 FF FF FF FF FF FF
2011/03/15 23:13:38 B5CCA280 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
2011/03/15 23:13:38 B5CCA280 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
2011/03/15 23:13:38 B5CCA280 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
2011/03/15 23:13:38 B5CCA280 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 52
2011/03/15 23:13:38 B5CCA280 24 20 20 20 20 20 81 46 55 BC 00
2011/03/15 23:13:38 B5CCA280 c emm reader sky-1 has no provider set
2011/03/15 23:13:38 B5CCA280 c EMM: GLOBAL
2011/03/15 23:13:38 B5CCA280 c emmtype global. Reader sky-1 has serial XXXXXXXXXXXXXXXX.
2011/03/15 23:13:38 B5CCA280 c emm UA/SA:
2011/03/15 23:13:38 B5CCA280 00 00 00 00 00 00 00 00
2011/03/15 23:13:38 B5CCA280 c emm is being sent to reader sky-1.
2011/03/15 23:13:38 B74D4B70 r wyrm emmtype=global, len=104, idx=45, cnt=1: skipped (0 ms) by sky-1

EMM Without "0000 separator", with 2 subs (this kind of emm was the initial motivation for the patch):

2011/03/15 23:14:05 B5CCA280 c emm:
2011/03/15 23:14:05 B5CCA280 82 30 AD 10 00 01 C0 43 02 00 83 90 81 40 88 FB
2011/03/15 23:14:05 B5CCA280 B0 4C D1 E7 ED D8 2C BD A1 F5 53 66 11 CA 0F 9F
2011/03/15 23:14:05 B5CCA280 4D B8 00 63 0C 9C C5 12 11 A7 AA 62 D3 09 49 86
2011/03/15 23:14:05 B5CCA280 35 5E 61 1A 71 CD DD 90 C9 A0 65 61 4A 4C 07 A1
2011/03/15 23:14:05 B5CCA280 AC 8A CC 87 1F CA CC F4 BF A6 89 26 13 DE 87 C1
2011/03/15 23:14:05 B5CCA280 89 76 A1 BD CE EA 20 24 A1 DC 00 0A F9 77 1A 98
2011/03/15 23:14:05 B5CCA280 41 F5 5D A7 FF 15 69 08 BB C9 68 29 35 AF 9B D2
2011/03/15 23:14:05 B5CCA280 BA 35 01 E7 3A 62 F1 BD DF 30 41 42 ED A0 52 21
2011/03/15 23:14:05 B5CCA280 A0 D9 B0 D7 BC D4 0B A1 DB FE F8 5D D4 B3 C0 10
2011/03/15 23:14:05 B5CCA280 02 06 02 E6 10 11 BB CC 16 90 14 40 04 06 93 56
2011/03/15 23:14:05 B5CCA280 19 9B 49 95 1B CA D5 97 F7 40 87 63 B5 0C 2B 00
2011/03/15 23:14:05 B5CCA280 c emm reader sky-1 has no provider set
2011/03/15 23:14:05 B5CCA280 c EMM: GLOBAL
2011/03/15 23:14:05 B5CCA280 c emmtype global. Reader sky-1 has serial XXXXXXXXXXXXXXXX.
2011/03/15 23:14:05 B5CCA280 c emm UA/SA:
2011/03/15 23:14:05 B5CCA280 00 00 00 00 00 00 00 00
2011/03/15 23:14:05 B5CCA280 c emm is being sent to reader sky-1.
2011/03/15 23:14:05 B74D4B70 r [videoguard2-reader] EMM request return code : 9020
2011/03/15 23:14:05 B74D4B70 r [videoguard2-reader] EMM request return code : 9020
2011/03/15 23:14:06 B74D4B70 r wyrm emmtype=global, len=173, idx=47, cnt=1: written (165 ms) by sky-1

comment:3 by lattjo, 13 years ago

Code is very easy to read and looks correct to me. It will for sure fail with cccam, might need some adjustment to address that. I don't know when I will be able to test this and commit it though. It could take some time.

comment:4 by wyrm, 13 years ago

Hi lattjo, thanks for your reply. Take your time, i will continue to improve and test this code while its out-of-tree. I will take a look at how cccam sends emms and, if possible, handle it properly.

Today i got a few more EMM-G errors on my log, from these EMMs:

8230 6A 00 0000
  F3 03
    63 FFFF ....

8230 9F 00 0001
  C04D 03
    77 FFFF ....

Code returned error because of unexpected sub-type 03, seems to be just ird-emm i will update the patch to skip these.

Last edited 13 years ago by wyrm (previous) (diff)

comment:5 by pooyair, 13 years ago

might fix in 4827, tnx to wyrm, sorry though i know this ticket is about emm and that fix is about ecm. as there were some change in reader of NDS VG2 Sky Brazil it's good if still exist reopen it with rev debug log >= 4827 please
Thanks

Last edited 13 years ago by pooyair (previous) (diff)

comment:6 by pooyair, 13 years ago

Resolution: fixed
Status: newclosed

comment:7 by wyrm, 13 years ago

Resolution: fixed
Status: closedreopened

This is not related at all with the ecm issue i reported on the other ticket. :)

comment:8 by lattjo, 13 years ago

CCCam has removed serial's in the EMM, so it will have zero byte instead. I think I added a comment when fixing shared EMM with CCCam some months ago.

comment:9 by wyrm, 13 years ago

It was r4644, im going to check it now. Thanks.

Last edited 13 years ago by wyrm (previous) (diff)

comment:10 by wyrm, 13 years ago

Im trying to implement this, i think that instead of checking an arbitrary byte inside the emm data we can make it safer by checking if the client is CCCam (ep->client->ctyp). So far seems to be ok.

BUT....

I think that writing unique/shared emms without being able to check if they really match the card serial may be a bad idea.

What if cccam sends us an emm-u with 3 subs? It's impossible to know which one to write.

For now, i will make it so it will write emms(u or s) from cccam only if it contains only one sub. Is this behaviour ok for you?

comment:11 by neoen, 13 years ago

Cccam extracts the correct sub-emm from original emm-u and sends always one sub.
Another client critical for vg2 emm that should be verified is vdr-sc, now is working.

comment:12 by wyrm, 13 years ago

Do you have information on how vdr-sc sends emm packets? I think that the only exception on current vg2 emm code is cccam. If vdr-sc sends untampered emm packets like oscam-dvbapi then it should work too.

comment:13 by neoen, 13 years ago

As I remember, vdr-sc re-assembles emm-u packet, it eliminates other UAs from packet but leaves all sub-emms.
Yes, I know, this makes impossible to know which sub-emm send to card and so all sub-emms should be sent.
This is not a big problem because the signature is verified only for the right sub-emm, for the others nothing happens (9020).

comment:14 by wyrm, 13 years ago

Are you really sure that vdr-sc is working properly on current svn?

In my tests, using dvbapi, emms with more than one sub-emm did not work correctly, only the first sub was being written.

comment:15 by wyrm, 13 years ago

Checked vdr-sc source code, it splits all sub-emms, and will send only the matching one or all of them (splitted), so it is not an issue.

But it would also fail on most emms from skybr, because of the "0000 separator" thing:

8230 AD 10 0001
    C043 02
        00
        83 9081.....
    C010 02
        06 02E6.....
        16 9081.....

Fails parsing on vdr-sc code, so it would not be sent. vdr-sc needs to be fixed too.
EDIT: Same for mgcamd, it seems that they are all broken.

Last edited 13 years ago by wyrm (previous) (diff)

comment:16 by wyrm, 13 years ago

Here is the current version of the patch, tested with oscam-dvbapi and mgcamd. Should work ok with CCcam and vdr-sc but it wasn't tested.

Clients should just pass raw emms like oscam-dvbapi does, as it is now they all need to be fixed because they fail to parse the emm structure above (and as a result they will not forward these to the card server).

by wyrm, 13 years ago

Attachment: vg2_emm.2.patch added

vg2 emm fix - version 2

comment:17 by neoen, 13 years ago

Your patch cannot work with cccam.
You are checking for cccam protocol, but the problem is not related to cccam protocol, the problem is cccam executable client.

comment:18 by wyrm, 13 years ago

Can you help me fix it? I do not use cccam here (and do not plan to use closed source stuff with known backdoor).

And anyway.. All clients which are doing emm parsing seem to be broken. They are not sending most emms for skybr. (they do not send emms with 16bit sub-emm length)

comment:19 by lattjo, 13 years ago

From videoguard_get_emm_type():

if (ep->emm[1] == 0) detected UNIQUE/SHARED EMM from cccam (there is no serial)

If the second byte of EMM is 0x00 the serial is removed = just let it through.
I'm not sure if this holds true in all cases.

comment:20 by neoen, 13 years ago

@wyrm
can you confirm that only emm-g could have 14 bits sub-len? I never seen emm-u with 14 bit sub-len.
Can you post an example of emm-g with 14 bits sub-len and more than one sub-emm? Once again, I never seen such as emm.
As lattjo wrote, emm[1] == 0 can be considered as cccam client indicator (that byte should never be 0).
Remeber that cccam only sends emm-u (at least for videoguard2).

comment:21 by wyrm, 13 years ago

The serial is not mine, so no need to censor it.

Unique EMM with 2 subs and 14bit length field. Each sub emm is directed to a different serial.

2011/03/20 10:04:10 32026B50   82 30 A9 50 03 44 62 75 03 2A 74 5F 00 01 C0 41 
2011/03/20 10:04:10 32026B50   02 00 7F 90 7D 44 08 24 E1 B5 0F 98 EC A7 EB 78 
2011/03/20 10:04:10 32026B50   A0 17 04 09 9C 41 5C 69 C5 C1 B8 89 67 7A 4B E3 
2011/03/20 10:04:10 32026B50   E2 38 23 D3 26 89 84 51 0D 83 0A 96 D9 39 A3 C0 
2011/03/20 10:04:10 32026B50   59 AF F9 A7 CB 0D 27 84 A0 03 C2 4F 08 47 A4 F1 
2011/03/20 10:04:10 32026B50   D9 D5 51 C8 F8 18 23 DC D9 FC 01 31 C4 F4 93 20 
2011/03/20 10:04:10 32026B50   BA C0 28 11 8F D2 77 67 49 91 01 4F 54 E1 5D F3 
2011/03/20 10:04:10 32026B50   F3 4F F4 1A 9A 9B 41 81 72 81 D0 57 0F E5 FB 2E 
2011/03/20 10:04:10 32026B50   6C 12 83 7D 11 D7 B6 43 AC E3 AC 9F 46 15 5D C5 
2011/03/20 10:04:10 32026B50   79 C8 C0 0C 02 00 15 90 13 44 08 E9 C8 2B D5 92 
2011/03/20 10:04:10 32026B50   BF D6 AD 01 F1 01 27 1F B9 84 51 19 

This example should be enough.. But here is a global with 14bits length and more than one sub (2) as requested:

2011/03/20 10:13:37 32025B50   82 30 AD 10 00 01 C0 43 02 00 83 90 81 40 88 7A 
2011/03/20 10:13:37 32025B50   AC 22 0B B6 EF 60 EF 67 4D 57 DC 93 9A 9F 7D 26 
2011/03/20 10:13:37 32025B50   21 E1 D3 1F CD 42 EB BC AB 8C 7B 53 75 E6 E4 F8 
2011/03/20 10:13:37 32025B50   3A CC A0 4B CE AB 12 0A 6E 62 0C 26 AA D3 26 69 
2011/03/20 10:13:37 32025B50   70 3C CB 38 49 E5 36 07 3F 5B 48 CD 6F BC FB B5 
2011/03/20 10:13:37 32025B50   CD 44 D7 84 21 28 DB 03 19 96 1E 0B 7B 02 E4 63 
2011/03/20 10:13:37 32025B50   73 9F A8 CF EE 26 69 81 BA 5B 56 5D 9E 85 D4 29 
2011/03/20 10:13:37 32025B50   DE 8D 56 42 B1 A0 C1 5A 4E 52 1F 00 CF B6 DF 08 
2011/03/20 10:13:37 32025B50   60 13 0F C3 7E 70 42 46 06 32 AD F5 44 05 C0 10 
2011/03/20 10:13:37 32025B50   02 06 02 E6 14 69 A6 13 16 90 14 40 04 55 99 FA 
2011/03/20 10:13:37 32025B50   AA 17 6B F7 26 80 6B 8D E9 93 1C 50 3F 7C EF 00 

Shared EMMs with 3 subs, each one directed to a different serial group is also very common here, i cant pin one right now (they scroll very fast without filters).

You probably never see these emms because the software you are using is broken. Change reader-videoguard-common.c so it doesnt filter anything and run oscam-dvbapi with -d128. You will probably be surprised of how much stuff isnt written. :)

Last edited 13 years ago by wyrm (previous) (diff)

comment:22 by wyrm, 13 years ago

CCcam thing with 00 as 2nd byte will be included on next patch! Thanks for pointing it :)

comment:23 by wyrm, 13 years ago

Sorry for pestering you guys with this emm thing. It definitely works without any changes.

The thing is.. If our software can't handle emm packets that are correctly handled by the sky equipment, then this "flaw" can be easily used as an attack vector. Even the uncorrectable flaw of not being able to filter serials on the 4th position (because of the 16 bytes limit) could be exploited to disable cards...

I'm paranoid as you can see. ;)

comment:24 by neoen, 13 years ago

@wyrm
sky-it does not use emm-s, in your patch seems that UA is 4 bytes also for emm-s.

memcmp(&filtertable[n * 4], reader->hexserial + 2, 3))

Are you sure? If so, fourth byte is 0?

comment:25 by wyrm, 13 years ago

Fourth byte is always 0x01 on skybr.

Current code is already 4 bytes for emm-s (reader-videoguard-common.c, get_emm_type()).

Also, i have a document describing EMMs and ECMs from skyuk, the document describes both, 14 bits length sub-emms and emm-s with 4 bytes, so these aren't a skybr thing.
I can point you the document if you want.

comment:26 by lattjo, 13 years ago

If it isn't colibri's document, please share the link. CCcam does send emm-s as well, I updated the code to support it a while ago.

comment:27 by wyrm, 13 years ago

Sorry, i do not understand why one would commit [4844] and [4845] if not because of NIH.

It breaks my patch and it doesn't fix the issues i pointed in this ticket/discussion.

It fails to do proper boundary checking, uses just 8 bits out of 14 bits for the len field, and will fail to write more than one sub if the length field is 14 bits.

Last edited 13 years ago by wyrm (previous) (diff)

comment:28 by wyrm, 13 years ago

Resolution: wontfix
Status: reopenedclosed

@neoen

You shouldn't just "skip" lengths, these should be checked everytime to properly respect boundaries.

846	      offs += 2 + 1 + emmv2;  // skip sub-emm len (2 bytes sub-emm len if 0x01);

This will fail if sub-len is less than 14 bytes.

850	      if (ep->emm[offs] > 0x07)  //workaround for mgcamd and emmv2 
851	         ++offs;

Your code will return OK if one of 2 (or more) emms succeed, so, you are silently ignoring potential errors.

Your code is less readable than mine, has less comments and doesn't work properly with dvbapi. I haven´t tested it with other cams.

You should also respect other developers, its clear that your work was based on mine, and even if your version still doesn't work you should have credited me in your commit message. I can see that this is your first commit to oscam. And in my opinion it was a very bad start.

You are probably not used to work on open source projects, but you will learn that human resources are the primary asset of an open source effort. "Not Invented Here" syndrome is bad, it will make people stop contributing to your project and in long-term this will be a lot of MORE work for you to do.

I really hope you will try to be a better Open Source Community Member from now on. Good Luck!

comment:29 by neoen, 13 years ago

@wyrm
check boundaries is done before using data, I'm sorry if code is less readable for you.
However, more than one year ago I wrote that code you are using till today, update for videoguard didn't work at all one year ago.
And more, I added (one year ago) support for vdr-sc, mgcamd and cccam client, and your patch would break at least vdr-sc and cccam, so you should respect oher users which does not use dvbapi.
I tested last code with emm-u and emm-g from dvbapi, emm-u and emm-g from mgcamd and emm-u from cccam and the emms you posted.
If you have problem with it, please post log with emm that cause error.

comment:30 by neoen, 13 years ago

Resolution: wontfix
Status: closedreopened

comment:31 by wyrm, 13 years ago

Support for cccam was already on 3rd patch.

Sorry, can't report you any errors, i've skipped your 2 revisions here, and im using my own code which works perfectly for my clients (dvbapi and mgcamd), does proper boundary and sanity checks, etc..

Your code from 1 year ago was buggy, the ticket was created to solve the issues on your code. And instead of solving them you reinvented the wheel and rewrote it in a way that the issues are still there. You used info from my patch and did not credit me in your commit message, there is no excuse for this kind of action.

It's plain and simple NIH Syndrome!

You can keep this ticket open if you want, but there will be no updates on it from me.

Bye!

comment:32 by wyrm, 13 years ago

Cc: wyrm removed

comment:33 by neoen, 13 years ago

Resolution: fixed
Status: reopenedclosed

comment:34 by wyrm, 13 years ago

ROFL!! It was not fixed at all!

Note: See TracTickets for help on using tickets.