MY three year old daughter has been crying all day as Cbeebies has not worked all day. I got home and played around with my third party box's and still no go. I have just pulled the original IQ2 box out of the cupboard and dusted it off and it fired up straight away.
Now my daughter is happy and I am crying.
It's got nothing to do with the box/card marriage.Originally Posted by zumka
A code word tweak is accomplished by altering the CW with a light algorithm prior to encryption into what you can call a tweaked code word (or TCW). The algorithm is loaded in advance on the secure silicon of the provider STB's such that after decryption the TCW is processed with the algorithm into a valid DCW.
Videoguard was emulated after an exploited box revealed the code. The hardware makers have made it much harder to find those exploits these days.
So if I understand that right, then to recover the DCW, either the CAM itself would need to know the "de-tweak" algorithm, or the card server (oscam etc) could do the de-tweaking & pass back a DCW to the CAM.
And I would guess the tweak algorithm itself could be keyed & tweak keys could be updated with EMM packets on a regular basis, which adds to the challenge of key recovery
I think that I am beginning to understand the complexity of the situation ... and it doesn't sound like its going to be easy to work around. Are we the first NDS market that this has occurred with & if not have any solutions been made available or considered elsewhere?
LeroyPatrol (03-06-11)
Ah cr@p so it aint looking good.
And just as I forked out $500 for a hardware upgrade and many man hours getting it working.
Ah cr@p so it aint looking good.
And just as I forked out $500 for a hardware upgrade and many man hours getting it working.
All part of the fun and games !
Who watches TV anyone
DUDE (03-06-11)
Apparently everyone in this thread...All part of the fun and games !
Who watches TV anyone
Wait till this hits europe then the hackers will come out of the wood work
DM800 DM800se Vu+Duo ET9000
Hmmm an interesting idea. I guess that would require somebody (or two people) to tune Austar and Foxtel on the same channel & capture a lengthy oscam log to retrieve the DCW and TCWs then try & reverse engineer how the TCW tuples translate/decrypt into the corresponding DCW ?
But would it have to be the same de-tweak for all, or could they possibly have implemented a STB-specific de-tweak key which factors in the boxkey as well? Or maybe they change the de-tweak key every few minutes with a specially formulated ECM, then it becomes nearly mission impossible...
This only just the start, the next few days zip,dont go blaming oscam for this, have you tried different cams?
I do not know if this fits into all thats been said.
Since all thats happened, I have noticed many EMMs shared and unique not written to the card ( EMMs skipped ).
Could this be a contibuting factor??
Is there any way to force those skipped emms to be written to the card??
Could this solve the problem??
I doubt very much they would do that. Just remember, any changes they make have to make sure that users with the card in the box do not have ANY INTERRUPTION WHATSOEVER, otherwise they would have customers crying foul.
Changing it every few minutes runs the risk of a customer missing one for whatever reason, and then being unable to watch anything until the next update.
I think I'm starting to get it now as well. I'm going to think out loud here.
Please feel absolutely free to correct anything in the following statement that is incorrect.
<begin theory>
Foxtel is transmitted in an encrypted format that, until now, has been decryptable simply by some combination of the information held on the smartcard and the serial number of the STB itself. All Oscam is responsible for is the capturing of the info off the smartcard, the combination of said info with the serial number in its config and passing the magic number to the video capture software which uses it to decrypt the stream.
In the last few days Foxtel has transmitted an update to their STBs saying "here is a codeword (similar to a pre-shared key in VPN terms)" and additional regular updates saying "use this key in combination with the smartcard and the serial number when you want to decrypt channels on transponder X" and so on for transponder Y and Z. Because the STB knows the codeword, the smartcard info and the STB serial it can successfully decrypt the stream.
But Oscam does not know the codeword so it continues to pass the "old" magic number to the video capture software which tries to use it to decrypt the stream and obviously can't.
A couple of thoughts arise:
1. In order for any solution Oscam would need to have a configuration or plugin option to do an "apply this algorithm or add this codeword to the info combo then calculate" before providing the "new" magic number to the video capture software. Does it have this functionality?
2. In order to get the codeword someone would either need to hack into the STB somehow and get it out of the config OR sit inline between the transmission and the STB and somehow ferret out the codeword from the data stream OR (as ian implicated) brute force it by trial and error guessing of the codeword and monitoring the "decrypted" stream to see if it really is decrypted. And as mentioned if this is a rotating codeword or algorithm well good luck
</end theory>
I've probably over-simplified here but doing a braindump has hopefully got it clear in my mind, has put it out there for correction and (eventually) may help others understand the issue in laymans terms.
Thoughts / Theories / Feedback?
In summary: I don't think it looks good
OSIRUS (03-06-11)
Hmm, maybe. A smart algorithm could manage packet loss intelligently, eg. by
sending an updated tweak key multiple times to minimise the chance of loss. Even a daily update would be an extra complexity to deal with in overcoming this obstacle.
But who knows what they've done in actuality?
anything created by man can be broken by man. i'm sure nds thought they had an uncrackable winner when they created videoguard. i'm sure hitler thought he had an uncrackable winner with enigma too.
the mind of the professional nds/whoever employee is always beaten by the mind of the 12 year old in the basement who doesn't have a girlfriend.
It has to be the same algorithm updated to all boxes because there is only one ECM stream and one valid DCW odd/even pair at any time. Just like Aus* has done (dare I say it that they have copied exactly what Aus* have done given that the teams often work together).
I'd imagine that a value in the ECM stream packets header is flagging whether the box needs to apply the algorithm or not. I believe the Irdeto ECM already has a built in identifier for that but Videoguard doesn't. Comparing non-tweaked and tweaked ECM's will give some clues. I'm expecting 12598H to convert tomorrow so I'll be logging some channels on that all day for all ECM's and EMM's. I'd encourage all others to do the same on not only that transponder but some others that haven't changed in case I'm wrong with expecting which ones will change. Turn on all debugging on Oscam and expect a large file. It could be the last chance to peer into the "open" lock.....
Thank god for people with a clue.
I'd like to help do this. But I run OScam for Cygwin, so I'll need instructions on how to do this.
Kind of. Here's my take on it in more detail. Others who are more technically literate with the details please feel free to correct me.
*IF* the problem is a tweak CW (and I am only going by what was suggested by davmel earlier) then its not just a "codeword" but an actual algorithm/software update which has been pushed to the STBs by Foxtel.
So what used to happen two days ago is that video packets are encrypted using a fast symmetric key algorithm with a CW that changes every few seconds. Your CAM (either in the STB or a software cam such as acamd) applies the decoding DCW to each video packet in turn & decrypts it to generate the raw MPEG2/4 data which it feeds back to 7MC or the STB's MPEG decoder.
Every few seconds, Foxtel change the CW and send an ECM update with the corresponding DCW as an encrypted packet which your CAM (or softcam) sends off to Oscam, which in turn talks to your smart card that knows how to decrypt the ECM. Oscam then sends the new decrypted DCW back to your CAM so that it can continue decrypting the video packets as they arrive.
What has happened now is that instead of Foxtel sending out the regular DCW in ECM updates, it is 'tweaking' the DCW by applying an unknown algorithm to it before putting it through the regular encryption algorithm that your smart card knows how to decrypt.
So what comes back out of the smart card after it decrypts the ECM is a tweaked DCW (or 'TCW'). To decode that, the CAM component of the STB has been updated (with a pushed software update) and it now knows how to transform the TCW back to a DCW.
But your softcam (acamd etc) doesn't know how to do that step, so it tries to apply the TCW in the role of a regular DCW video decoding key, the video fails to decrypt and you get a black screen when the softcam gives up.
So the problem isn't really with Oscam, its doing the smartcard decryption job just fine. The problem is with the softcam not being able to handle a TCW.
However, a fix could be implemented in either the softcam itself, or in Oscam, which could be enhanced to de-tweak the TCW before outputting it back to the softcam.
The trick is that it's not just a 'codeword' but a whole new (and unknown) algorithm that would need to be implemented here.
It's also unknown whether that algorithm is itself keyed with a rotating key - if so then a decryption algorithm would need to be able to remember this key whenever it is updated (which could raise a whole new 'update' scenario like for EMM updates on the smart card, but in this case the key would need to be 'remembered' on the PC itself)
Sitting inline between the transmission and the STB won't help, we can already see the raw transmission packets but until we know the de-tweaking algorithm they aren't going to help us.
I wasn't suggesting to brute force by trial-and-error guessing of a codeword or algorithm and monitoring the decrypted stream.
What I think that davmel was suggesting earlier is that the Austar and Foxtel video streams are in fact the same, ie they use the same CW to encrypt the video packets (is that really true, they are entirely different systems irdeto2 & NDS?)
If that's the case, and Austar are still sending ECM updates with untweaked DCW's while Foxtel are sending ECM updates with corresponding tweaked TCWs then it would be possible by capturing both Austar and Foxtel feeds to produce a set of DCW/TCW matched pairs.
Then collect enough of those and you could start to use cryptanalysis to infer how the tweaking algorithm works.
Disclaimer: I know just enough to be dangerous...
Last edited by ian.d; 03-06-11 at 01:31 AM.
I suspect that they would have the same decryption key (or DCW), as there is only one iteration of the channel. I don't see how you could easily encrypt one video stream with 2 seperate decryption keys.
An easier way to do it would be to send completely seperate ECM's for each encryption system, and those ECM's would go through the decryption system and end up as the same DCW.
Yes, that's what happens in simulcryption. A single code word is used to encrypt the video/audio streams. That single CW is input into two or more different encryption systems to produce multiple ECW's that are then transmitted with the encrypted video/audio streams in ECM packets. Any decoder that has a valid card to decrypt any of the ECW's in each ECM can be sent back the original CW. Two cards using different encryption systems will still return the same CW at the same time assuming they are both authorised at that time.
No. Austar hasn't transmitted any normal (untweaked) DCW's since April 2008. However the algorithm was extracted from exploitable older STB's shortly after and is now inserted as software code in tweaked versions of Oscam that has been discussed for nearly 18 months now in other threads. Using the tweaked version of Oscam will give you valid DCW's back to clients.If that's the case, and Austar are still sending ECM updates with untweaked DCW's while Foxtel are sending ECM updates with corresponding tweaked TCWs then it would be possible by capturing both Austar and Foxtel feeds to produce a set of DCW/TCW matched pairs.
Posting Permissions
Bookmarks