Reply With QuoteVery nicely put.
How to 'revive' the gamma ...
Irdeto ?? – the changes ... some comments and information ...
Those of you who are interested in having a ‘go’ at reverse engineering a ‘working’ A* ‘box’ – to determine what has changed and to ‘revive’ the gamma ... there are a few things we can do to bring us up to the current state of technical play ...
1. Find out about Irdeto system and its operational principal – your friend (google) can help you here. There are lots of papers on this subject and you can also look at the Patent documents – they usually have useful information about ‘key’ aspects of the system. BTW – Patents indicate that Irdeto was ‘invented’ by South Africans.
2. Get technical data on the A* ‘boxes’ which work with current data streams. In particular – open one of the boxes and have a look at the various memory / flash devices as well as decoder chipsets. Get manufactures data sheets on these chipsets and where applicable any application notes of SDK for their suppliers. There is a wealth of information in these documents.
3. Do some comparative logging – gamma logging before the change and current logging with gamma as well as legit sub card. Try to relate the logs to the Irdeto data streams and see how it ‘differs’ from what’s published (from 1 above) and what is being received.
4. If data does not correlate – look at the H/W chipsets and specifically application data as to what CAN be done with the chipsets (other than firmware) that could account for the discrepancies.
5. Get your hands on the firmware used in the ‘working boxes’ – dump it from a working ‘box’ and disassemble the code (you should know what processor already) – if you don’t understand what’s happening. Do same for a ‘old’ (same) non OTA updated ‘box’ – compare the two firmwares – note any changes. Do same for memory / flash / eeprom dumps – as some data could have been written to these components and not contained in the actual firmware. Study the results and relate these once again to the Irdeto operational principal – does it satisfy – if not where does it differ.
6. If you are still not getting with all of the above – get some high end test equipment – preferably a stream analyser as well as a multistate logic analyser / in circuit emulator – do some ‘real-time’ process analysis on the ‘working’ and ‘not working’ systems. If you are familiar with softice – then you will know what we are trying to do here – since we cannot use a product such as softice here – we need to use real H/W devices which are hard to lay hands on for most of us.
All of the above is some starting points – so we can determine what has happened and what recent changes were made. The ‘real’ answers to these questions might yield sufficient information for us to reverse engineer the changes and ‘revive’ the gamma.
Remember the emms and or ecm's are sent to gamma as before, but (probably) now with different info in the headers.
So, how does the cam tie into this (as is the popular theory), it passes on the right information to the gamma, may it be serial, or group or card within the group for the emms.
Now the ecm's depending on what channel is in use, it passes on again the specific ecm regarding that channel. This is most likely in a ‘raw’ state as sent by the provider, with the addition of the header.
The DW's from the gamma are encrypted by the camkey (as sent by the cam), the only thing the cam does in this case is decrypt them again, and then send it on to the demux registers.
The camkey algorithm (if not changed) is known (to the gamma developers), being the same as previous versions of ‘working’ cards. Meaning that if we have the CW and the plain DW, the gamma card will figure out the PSK and we get the pics.
This is why the gamma is still very important here – it is the ‘key’ and it has the algorithm within it – something that A* could not kill without bringing down every legit card.
So – don’t dump your gamma – even if it’s not working right now – you will need it!
So the changes are all outside the gamma – if we can find out exactly what these changes were – we should be able to ‘reverse’ these.
What we need to do is to is to analyze the data going into the gamma – before and AFTER the changes, this will be a valuable source of information – and lead us to a better understanding of what techniques / method was used to alter data going into the gamma.
In short – the gamma still has the correct algorithm to decode – but the data going into the card has been altered – we need to change it back to a stream it can recognize and decode
Are there are sufficient technically astute members here who have some of the above resources and know-how and would like to work together on reviving the gamma?
If there are, then we need to ‘run’ this as a formal project – similar to a repository for software development – we all are given tasks, we all have our ‘little’ bit of code to write (metaphorically speaking) – and check it into the repository of knowledge. Once a system like this is launched – we will have a solution (or at least know if one is possible) within a short period of time.
Is this forum the best place to ‘run’ this project?
I personally don’t think it is – we would need to work together in another ‘virtual’ space with a formal ‘check-in’ check-out process – something this forum cannot provide.
We should appoint a project leader – preferably the most knowledgeable person on Irdeto and points 1 to 6 above is a good start – and follow with specific tasks being allocated to individuals who would then report their findings to a project co-ordinator.
Remember – complex projects (including this reverse engineering task) can be broken down to manageable ‘bits’ when we all work together – the solution is then well within our reach.
Hope the above rant will lead onto some inspiration – otherwise it will be a slow process for a single individual – who at the end of their hard work will most likely be very reluctant to share the results
| Look Here -> |
Very nicely put.
Now to assemble the team and give them a name ??
I reckon the "A-TEAM"
hang on
Maybe thats what they call the techs at "A"ustar
When you do things right, people won't be sure that you have done anything at all
[Cynic On]
It may be a great idea, but what's to stop Austar planting a member on the "A-Team"
That would make it better, they got the answers
When you do things right, people won't be sure that you have done anything at all
ROFLOriginally Posted by best4less
That would make it better, they got the answers
LOL ... yeah, that would be handy
Good Info and no doubt a challenge.
I believe eyesee has put up some good info here.
A couple of points I would like to make that might help some additional brainstorming ideas and plans:
1. Was there much difference between the old "Public" Gamma and recently defeated Seller Gamma e.g. final error messages and "death" symptoms same or different?
2. With the death of the sellers Gamma I believe that a number of A* subscriber boxes also died or lost access?
3. Is it assumed that an over the air STB firmware update (with an Irdeto signal change) was implemented to only allow A* subs boxes to receive Irdeto card access i.e. preventing both the Gamma and Irdeto sub cards to be readable in any non A* STB?
Food for thought
One was public details that Austar killed. Second is unknown at the moment but some suggestions are extra encryption layer.1. Was there much difference between the old "Public" Gamma and recently defeated Seller Gamma e.g. final error messages and "death" symptoms same or different?
Other 2 you are way off
Decrapper
Spot on Gammas still update ok the only thing i have found the control word now has 8 more bytes which is most likely an extra encryption layer.
You can see this if you run yanksee you will see 8070 and 8170 control words are 8 bytes longer you can compare against Aurora id2.
This will require a cam update to fix not a card i believe, if someone could check card coms on aus* box then on 3rd party box to confirm.
Cheers
Blade
Just a question out of curiosity for the electronic repair gurus.
If an encrypted signal is decrypted by card in a cam (which I presume is a type of card reader).The decrypted signal goes from cam to the tuner and video/audio signals processed and then output to monitor/TV for pictures & audio.
If this is correct (cam reads cards) then why cant a Cam from an Austar box be put in a 3rd party box.
The provider box probably has an embedded cam, but a real electronics wiz could probably manage a Mod of this type.
I just wonder could it be done and would it work?
I`m sure their are alot of people trying all sorts of mods to cams. I dont know crap when it comes to cams. But my fingers are crossed for all the hard working guru`s out there.
interesting concept, but you will find there is more to it then changing the chip, there are alot of other things that need to be taken it to account.
Tagg
hmm , I dont have a whitey was tempted to get one before this all fell out , but didnt *s*
But I know someone who got one about a week before this happend , poor bastard LOL ,
Ill try and borrow it and do a season log of card cam comms ,
however I can only do this on a 3rd party box .
Ill try on the weekend as I need to align to c1 as Im on select here .
this on my part will purly be curiosty as to whats going on here .
Im suprised that Knowbody has produced a card/cam log with details edited out , I mean so many guys have them and nobody has bothered yet .
Sam
posted on primeevil
Sam
can't log in ...
whats posted on p.e?
card/cam log details.
a cardcam log in a thirdparty box
Would be good if someone can provide one in a provider box to see the difference
.
Sam
Posting Permissions
Bookmarks