Ok guys, I saw this posted on a private site, but I was given permission to post this freely as to shed some light on the ECM theories and to help those with knowledge to solve the issue:
I have been trying to figure out what is going on with the current DN ECMs, but it is unfortunate that there is not too much discussion about ECMs in public forums these days. That is too bad...in the past, the hobby came alive when we were challenged by the providers; nowadays, either everything is swept underground, the hobby is really dead, or folks just don't care any more. :-(
At any rate, I have been hearing about a CW counter that was added to the card as a REV update that tracks the number of CW request, and if there are too many due to multiple tuners (like what would happen if you are running a server), the the card holds that information which is later detected whenever DN sends the "investigator" EMM or ECM...if too many, then wham! Card finished. I have not seen where anyone actually posted any CONCLUSIVE test results to see if this was actually what was going on, so I decided to risk my own card to test this.
I had a newly activated card from my VIP222 that I used for the test. This card was NEVER in a server before the test, so there was no chance it had a high CW count in memory from a past server test. We are talking virgin card, newly activated back on the late December, and then was put directly in a server on a PC running RQCS 1.09. In my config, there was only 1 client (which was my VIP722) and I had ALL EMMs (g,s,u) blocked. The only way the card could be updated was to put it back into the receiver, but I never had to do that...If there was a key change, then I must have already had the key on the card, or it came through even though I had EMMs (g,s,u) blocked!
The client (VIP722) is running firstname.lastname@example.org on a PC that is hooked to the receiver via wired AVRx purchased from digital clinic...the setup runs perfect and freeze free on software version 725. I usually run receiver in "single" mode and the second tuner is used for picture-in-picture on the same TV from time to time. For the most part, the second tuner was tuned to channel 101---but occasionally, I am watching a PIP with a game and something else. The bottom line, there was never more CWs sent to the card than would happen with a dual tuner VIP. My sub is pretty much all dish has to offer (America's everything, platinum HD, Fox sports, and one porn subbed,etc...), but I only watch a few of the same channels and those between 300-400 for movies. For PPVs, I had a second line in the config and hooked to a P$erver. I watched PPVs only rarely, so I rarely was on the P$erver. That is the setup that I ran since late December, and I STILL GOT HIT BY TODAY'S ECM (1/24/13)!!!!
Now what could it be? It is definitely NOT a counter tripped in my case! Also, the VIP722 was not cloned to match the VIP222 that the card came from....could THAT be an issue? There were no EMMs sent to the card...is it possible that the card must be in the correct IRD to received a specific bit of code in the form of a EMM/ ECM, but if it is not there when a different EMM/ECM checks for it, then WHAM---Hit the card? Is it possible that the current cardserver (RQCS?) is allowing something dirty to reach the card that the IRD filters out, and the ECM whacks the card if it is there? Do we need to update the cardserver applications to include some type of blocker code to allow only known CW request? The question about the CW counter does not hold water in my test, but I won't rule it completely out since it could be happening in addition to something else! The "something else" is the key!
Tell me what you guys think!
Ok guys, I really trust this person as a thorough tester, and I take him at his word that everything he said was done was actually done. If anyone has any questions, please feel free to chime in and I will run them by him for his input. Lets crack this flucking nut!
I am by far not an expert but I remember in the past there have been counter measures that check the specific ird and card communication and verification that the card is in the correct ird or in a ird. This call and response must be made to allow video. However, I have not heard of it taking out the card. That being said, since things have changed so much, that this is a distinct possibility. If this is true, something needs to be done or cards will be going down very fast if a counter measure is implemented frequently.
As far as his concerns about the lack of community help and feedback, they are warranted. Everything from legal issues to the lack of tools and the ability to get information from the card itself takes many out of the game.
YES, the coding community has gone underground and this is a small group that takes no new members unless the coder is or has been trusted for many years.
Take my opinion with a grain of salt, I am trying to give an education opinion and an attempt to get some communication going in a stagnate thread
From what I just read seems like maybe feeder box is letting the killer emm thru when original ird's don't let it thru... Just MHO...
I think charlie checks if the card is in a legit receiver and if so then okays the card, if not then marks the card for hit later.
Check card for IRD Info
IRD response is normal
IRD response is not normal or no response
Mark the card
Seems pretty easy to me...
So the questions is can you run a server with the card in a receiver? Or can you spoof the IRD response?
Do they get damaged with only one client?
I am a complete n00b as well.
but here we go.
We don't know whats going on as we can't publicly open the cam.
Lot's of speculation.
Dumping the dataspace shows desubbed.
Who knows so much bad info going around.
id it was ECM counting then we coudl rely on the 1+1=2 for determined amount of time,...... 3 weeks typically......we know the 1 weeks hit took out legit subscribers.
we know its coming on a new emm...... or a mecm.....
mecm makes more sense ... because the key changes allow the "hit' cards to work again.
and the malicious ecm comes as a chennel req.
caould be as simple as a ird sending a req that should never be allowed.....which would resultin more ecms...
or a eastern arc hitting a western arc cam
or a facking simple time/date check from ird
those would seem like more ecms...
these cam are definitely marked.
but CAN process emms... this is for sure knowen
Support your starving artists.
Anybody tried using a setup other than rq/fs based sw?
Support your starving artists.