crabber (29-07-11)
Older cards are blue cards which can still be shared. The newer ones cant be anymore due to these changes. I reckon you guys in the UK will cop it soon.Originally Posted by crabber
BTW, send us some bananas
crabber (29-07-11)
Thanks guys it is a bit more clear now. I cant remember if I have posted this before but we have a couple of NDS channels here that give similar symptoms with cccam. They return cw but black screen. However Oscam does clear them so many people have been changing to Oscam in the (perhaps forlorn) hope that if the changes are extended to the entire package we may still get a picture.
I suppose if it does happen here there will be many more people affected and so more effort may be put into finding a solution.
Problem is with other smaller providers that have introduced hardware pairing the only EMU's capable of overcoming it have been non public and developed for (my pet hate) payservers.
weirdo (29-07-11)
This is because of a bug in the initial NDS2 decoding algorithm implementation as it appeared on the net several years ago. For every ECM with true length divisible by 16 it returned an incorrect DCW (that's why only some of the channels are affected). Someone fixed that issue for OSCAM a couple of years ago. I bet CCCAM developers simply didn't pick that fix up. This is one of the biggest advantages of OSCAM being open source.
Yes Oscam can read the boxkey from our NDS3 cards, where Cccam cannot. This isnt a major problem as it can be added to config manually. I may be wrong but my cynical opinion of Cccam updates is that they only happen when sales of Dreamboxes fall.
I understand what you are saying about ECM length but oddly these two affected channels have only fairly recently been black (with Cccam) They are not even premium channels, both are FTA on digital terrestrial.
That ECM length changes from time to time. So channels affected might change at any time.
The ability to read boxkey is not important, as it can be overcome manually. BTW, OSCAM isn't perfect at this either.
We just got our Foxtel (cable) back up this morning after a blackout on Thursday caused a fault which killed the Foxtel & cable internet.
But I'm now getting black screen on 161 HITS+2, 160 YOU +2, 158 FOOD+2, and 635 DISC TURBO +2. I'm also getting a "service is scrambled" message on 180 NITV. All other channels are unaffected (but I'm not subscribed to any movie or sports channels currently)
So I put the smartcard back into the original STU and all those channels come up.
And yes it's a bluey.
Anybody else affected? Is it the beginning of the end for blueys?
Hmmmm, all on the one transponder (12052V). Looks ominous.
But looking at the ECM headers it hasn't changed (at least on sat).
It's a possibility that the cable broadcast of those channels in one area is having a custom ECM stream sent out to minimise any complaints that may be caused with the older STB's that were having problems with the previous widespread changes. If the problems are resolved the new format will be broadcast on sat and cable for all transponders. Seems a little haphazard to be rolling out changes in the field before they have been fully tested in the lab with the simulator and test boxes.
Last edited by satdancer; 30-07-11 at 12:36 PM.
Those channels ok on bluey sat.
Edit: wrong info
Last edited by bambbbam; 30-07-11 at 12:42 PM.
* Bill Paxton is the only actor to be killed by Alien, a Terminator, and the Predator.
I've dumped some ECMs from the various channels, see below.
The channels giving a black screen have the same ECM length as a working channel, but the NITV which gives the "service is scrambled" message has a shorter ECM.
101 (working):
80 70 6B 00 00 01 11 8A 1E 13 E5 FF FF 75 92 15
21 80 01 00 01 01 00 70 55 7F 0A 5F EA F3 32 DE
9B 32 7B 00 00 90 47 C0 01 AE EE 78 8E A5 DA 1C
9B A6 B5 DF CF 00 E9 24 3B 8F 80 36 3C 3C 61 FC
3F 2A 32 4F 09 8D 0D F4 0E E6 66 FA 32 1A E3 8A
CD AB 3E A8 1D 65 D7 63 38 A4 3E 78 ED 78 A0 0F
CC A4 9E AF FA DC F9 7A 8B 32 6A 11 9D F6
160 YOU +2 (black):
80 70 6B 00 00 01 11 8A 1E 15 65 FF FF 9B 42 15
21 80 01 00 01 01 00 C8 55 7F 0A BF 8C E6 88 A8
29 EE A1 00 00 90 47 C0 01 28 36 6F 12 99 40 CC
8C 79 64 1C 06 9A 8A A0 AE E4 2C D2 8C 55 A8 E6
44 92 FD 94 A7 31 AE 4A 87 B9 64 C4 A1 F8 38 0F
11 74 2B F4 A9 1E 09 C3 B5 2B 11 C9 89 C2 EE A5
75 83 4C 85 93 51 76 4C A6 EE 86 AB 28 A4
161 HITS+2 (black):
81 70 6B 00 00 01 11 8A 1E 14 0A FF FF DD 0B 15
21 80 01 00 01 01 00 77 55 7F 0A 51 C8 50 56 5F
4B 8D 24 00 00 90 47 C0 01 DA 48 6D 5F 52 12 06
5B 54 9E 65 18 75 66 CB F3 77 CD E8 3C 74 2A 74
74 E1 FE 30 A8 CF 8B 30 1B 1B 3A 3C 52 A9 B0 F5
1C 2F ED 98 C3 0C DF 2F 0D 50 8D 06 8D 7D 9F D6
6C F5 C6 DB E9 3F 8C 29 9B F0 86 35 58 0E
180 NITV ("service is scrambled" message in Win7MC):
80 70 5F 00 00 01 11 8A 1E 14 2E FF FF 7B 2D 15
21 80 01 00 01 01 00 5B 49 7F 0A 76 89 39 DB AA
90 C9 5B 00 00 90 3B C0 01 89 DB 34 4F 0A D9 C2
DD 37 1F EB 1D DE F7 34 F9 99 B1 19 E9 77 F9 29
3C 08 D3 FA 65 CA 15 DF 6F B0 13 EA 42 D7 83 5F
70 05 A4 56 D2 85 0B 20 D5 D4 C7 E9 EF AE 60 20
8E 68
cobra679 (30-07-11)
I've highlighted the relevant value in the ECM header which if it stays as zero means the old ECM structure format is being used. i.e. no extra NDS "options" are being used.
If it was a "01" value then that would indicate the new ECM NDS options format and would require an extra 5 bytes of values following it.
If it was a "02" value option as used by Sky Italia then an extra 2 bytes of values would follow it in the header.
So nothing unusually different. Don't know why you're getting black screens. Just to check, do the returned DCW's from the card contain valid checksum's?
Ok here is a bit more of the log for channel 160 including some of the cardreader response messaging & the DCW:
r ecm:
81 70 6B 00 00 01 11 8A 1E 15 6A FF FF D2 C0 15
21 80 01 00 01 01 00 82 55 7F 0A 0D 40 3B 83 63
05 CB A9 00 00 90 47 C0 01 E1 3E E4 13 9A 66 EB
2F 2F 43 62 99 3D 2A DE A8 9C 61 A4 1D BF 04 EB
C2 05 4A 53 C3 51 22 2B A7 17 D5 CA B7 DB A0 34
AB 9A 74 57 40 83 E8 85 88 73 2A 97 59 E8 4A B0
62 96 27 D5 25 67 A6 10 6F 22 4A D1 59 BB
....
r reader: fx ecm: BE73 real time: 499 ms
r store_cw_in_cache: ecm=BE73 grp=1
c ncd_send_dcw: er->cpti=0, cl_msgid=4, 81
c send 31 bytes to client
00 1D 00 04 00 00 00 00 00 00 00 00 81 10 10 00
00 00 00 00 00 00 00 3B AA 95 7A A7 88 93 C2
c wmc (090B&000000/59DB/6E:BE73): found (508 ms) by fx (of 1 avail 1)
c cw:
00 00 00 00 00 00 00 00 3B AA 95 7A A7 88 93 C2
And Channel 180 (NITV):
r ecm:
80 70 5F 00 00 01 11 8A 1E 14 2E FF FF 7B 2D 15
21 80 01 00 01 01 00 5B 49 7F 0A 76 89 39 DB AA
90 C9 5B 00 00 90 3B C0 01 89 DB 34 4F 0A D9 C2
DD 37 1F EB 1D DE F7 34 F9 99 B1 19 E9 77 F9 29
3C 08 D3 FA 65 CA 15 DF 6F B0 13 EA 42 D7 83 5F
70 05 A4 56 D2 85 0B 20 D5 D4 C7 E9 EF AE 60 20
8E 68
r answer from cardreader fx:
62 E8 81 07 39 3C 8A 5F 87 3E A9 C4 A6 58 4A BA
8E 2E 0D A7 3A B6 CC BC 02 E6 F5 7B 0F F8 40 01
99 E8 00 55 AA 34 D2 EE 04 B8 BD 7E 17 C3 41 2E
BF 58 0D 47 50 4D 50 8C 52 A0 EB 49 91 21
r [videoguard2-reader] classD3 ins54: status 90 00 = ok but cw=00 -> channel not subscribed
r reader: fx ecm: E57D real time: 415 ms
c ncd_send_dcw: er->cpti=0, cl_msgid=2, 80
c send 15 bytes to client
00 0D 00 02 00 00 00 00 00 00 00 00 80 00 00
c wmc (090B&000000/7D08/62:E57D): not found (422 ms) (of 1 avail 1)
c cw:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Hmm, am I reading that right - it thinks I'm not subscribed to NITV? Because NITV works just fine from the Foxtel STU. And it used to work from my W7MC too, up until now.
Can somebody identify from the log I posted here, does the checksum compute on that CW for channel 160?
Thanks
Yep, the checksum is valid:
3B+AA+95 = 7A
and
A7+88+93 = C2
So something else is at play here....... Dare I say a tweak key because that will still return a valid DCW.
Perhaps Foxy has dropped the idea of using the NDS header encryption option which worked for the orange cards and opted for something customised for the blue cards (like what Austar did) and implemented that as fully post processed in the firmware.
That is weird. But Foxtel appreciates your feedback ;-)And Channel 180 (NITV):
r [videoguard2-reader] classD3 ins54: status 90 00 = ok but cw=00 -> channel not subscribed
Hmm, am I reading that right - it thinks I'm not subscribed to NITV? Because NITV works just fine from the Foxtel STU. And it used to work from my W7MC too, up until now.
Have you tried flushing your channel settings in your box. It could be some issue with the PID numbers for ECM streams if they changed recently. I'd suggest clearing all your channels and doing a full scan of all channel again.
I just did a scan of NITV and it only has a single ECM stream for Irdeto. No ECM stream is listed in the PMT for the channel!
Last edited by satdancer; 30-07-11 at 11:49 PM.
ian.d (31-07-11)
The PMT channel???
my missus must watch that continuosly!
__________________________________________________ __
Statistically, if you wait long enough, everything will happen!
Ok I removed the affected channels from DVBlink and did a rescan. NITV now works.
But the channels that were black screening previously, which were all on transponder 247000 (H6950/QAM64) are now AWOL, a full network scan didn't find them at all.
That tp used to have HITS+2, FOOD+2, YOU+2, TURBO+2, 7TWO & GO (I hadn't observed the loss of 7TWO & GO, because I get those preferentially from FTA).
But how do I find what TP they have moved to if a full network scan doesn't find them?
(I guess after all this, it isn't a ECM problem at all so perhaps I should move this discussion to another thread, but there's nothing else much being discussed here right now...)
Addendum: Meter shows signal strength on 247000, just no channels.
Last edited by ian.d; 31-07-11 at 10:18 AM.
I get the above channels OK on
12052 V 27800 DVBS
don't know if that helps or not ?
Last edited by OSIRUS; 31-07-11 at 11:40 AM.
Become a Premium Member and support the Austech Forum
Easy, use TSReader for example and look at the NIT table which will show each cable multiplex frequency and under each entry it will show which channel services are on each multiplex. It will tell you what symbol rate and modulation you need to use.
I just wondered if anyone had an update on this issue - and if any progress is being made? Is it being discussed in more technical terms on any board?
A bug was raised with OSCAM, not much came out of it.
The most technical discussions are over at OSCAM, its a bit of misnomer as its really fishing at this stage.
The algorithm used doesnt match anything I've previously seen and it may involve yet again attaching to the bus on the cards to find weak uses of the algorithm, short of that it's going to be difficult to reverse engineer whats been done.
There are a few recent developments for mapping chips and their algorithms; in fact there is a real development in the real world in this area.
You are welcome to join the oscam forums and follow the ticket information, short of a rollout across Europe; the man hours required to resolve this and the lack of a firm methodology to approach this a rather hard possibility.
James
They're offering a free installation of a multi-room box. What's the chance of it being a bluey?
zero
Posting Permissions
Bookmarks