What is the best tool for dealing with IRDT II?

[tonyboyth]

Hi there,

First of all, I wanna say that I not Australian. The country that I have been living is a little bit up north above the equator.

At the moment, in my country there are a couple of PayTV operators. And as far as I know, there are some people who have been using GMMA card over here. It is kind of attractive me because it cost me around 15K AU/year for full subscription to the biggest provider here.

I have seen some of you mentioned about "GMMA card" and "Seller Card" and I think both of them will be for IRDT II. Then I will try to get one for my experimental soon. To get a real card (either of them) is not too difficult but How ever, as a newbie the most important thing is to understand how the whole thing work. Then, I do have some questions;

1. As mentioned in "how to create your own GAM file", I do have to log the EMM stream, so far there are many of them out there that I can download, then what is the right one for logging IRDT II?

2. I have been logging for almost 3 days now, I saw only "02" or "03" lines, very few of them, but for "CB, not even a single line. Then, is it possible to create a GAM file by using either "02" or "03"?

3. I found some tools like "dlog", which has a function to evaluate some HEX to get HMK from my card (4.1/5.3), Is that the correct HMK?

4. If I got everything, HSN, HMK, Prov ID 00 and 10 (I hope that HMK should be the right one) then How can I manage to write those things into my GMMA card because I do not know how-to generate "signature"?

5. I have seen in some text compiled by "CtrlAltDel" on some explanation for writing "crd" script but all of the tools and methods are for IRDT I, so is there any tool for dealing with IRDT II card?

Please accept my apology if I asked to many questions, all you guys are very kind I know that.

Thanks in advance.

Tony.
ps: if you guy just provide me a link or so that I can study by self that would be great, thanksssss

[gw1]

If you're interested in how things work and are prepared to spend time and energy learning for learning's sake then good on you. You've made a good start and will find lots of interesting hidden puzzles to explore.

However a large number of people, the majority I think we can safely say, study these things only because they want to obtain Pay TV reception more cheaply. If there was a program they could download and run that would magically give it to them they wouldn't spend even ten minutes reading about card processor types, file types and formats, interfaces, programming protocols, emulators, master keys, session keys, EMMs and ECMs, provider ids, country codes and so on.

Irrespective of your country or what satellite or cable system you use, to view an encrypted program you would need
1. a card emulator program with cryptosystem-specific algorithm and keys necessary to negotiate access to the data stream (eg Irdeto, NDS, Seca, Nagravision)
2. a provider-specific set of keys for decrypting the DVB control words (because emulators are useless without valid keys)
3. tools for installing the above on your hardware (clone card or PC/receiver emulator)

No working emulator or key files for GAMMA are public at this time, and you're not likely to find working ones for GAMMA or its successors on public sites in future, at least not on the scale witnessed in previous generations. To understand why you need to appreciate how clone file distribution has evolved, because GAMMA distribution logistics are unlike that of previous generations of card cloning.

Back in the Goldoic era, emulator and key were sold together as a unit to pirate retailers (sellers) who sourced blank cards themselves, programmed and sold them individually or in dish+receiver+card packages. When keys changed customers returned to their resellers who needed to obtain a replacement file from their supplier - they couldn't make it themselves. Blanks and programmers were both easy to obtain, and sellers weren't hard to find either, so it was in sellers' interest to maintain secrecy. But clone card discovery was inevitable; identified keys were deactivated and potentially traceable back to the originator.

To avoid a single point of failure crackers began supplying key extraction tools separate to their emulators. These enabled sellers to use their own subscription cards, making the crackers less vulnerable and releasing sellers from dependence on them for updates. Sellers now had greater incentive to preserve security among their clients, plus a means of fixing customer cards if one of their accounts was busted. Eventually though both the emulator and key extraction method both would become public, at which point every customer saw the opportunity to earn money from selling, piracy exploded and radical countermeasures became necessary.

Irdeto 2 required a fast crypto coprocessor which necessitated the use of a newer, more powerful card that was harder to obtain. But rather than rely on scarcity of the new blanks to hinder unlicensed proliferation of their emulator by end users, the GAMMA developers used the card's strong crypto not just for emulation but for licence control of the emulator itself.

• They programmed the blank cards with the emulator (algorithm and cam negotiation keys specific to each provider), same as before
• They produced tools for key extraction, same as before, though these were more tightly controlled, initially distributed only to regional heads (far fewer in number than previous generation sellers)
• The emulator contained a loader allowing keys to be updated by sellers, same as before
• The extracted key files were encrypted, readable only by the card loader (some emulators of previous generation did this but most didn't)
• The emulator's loader also supported emulator/key updates to be applied, sent in encrypted form from the developer to the sellers. That the emulator file only existed in encrypted form was a new development - in previous generations it was unencrypted. Because of this encryption the file could only be written to blanks that already had the developer's own loader, preventing sellers or third parties from cloning it onto independently-sourced blanks. ie the only person having the card program in unencrypted form was the developer himself. The encryption also hindered providers' efforts to develop countermeasures targeting emulator imperfections, since without a binary to reverse they could only discover discrepancies by trial and error.
• The emulator was configured to mimic a benign memory card when initially distributed, to avoid problems if intercepted in transit by customs or thieves. To turn off the mimicry and enable normal operation the developers preloaded a "transport code" known only to the regional distributor and his sellers, who supplied it using special loader commands. The loader had provision to shut down permanently after repeated attempts with an incorrect code.
• The emulator had two modes. One was where it booted to the loader and issued its own arbitrary "GAMMA" ATR for administrative purposes (recognised by tools supplied to the distributors by the developer), handling commands for regional/provider key entry and emulator update. Another was where it booted to the provider ATR. But the emulator and the loader are just different functions of the same program - there is no GAMMA "operating system" to speak of apart from the alternative ATR and loader commands (known to old-timers as the monitor or bootstrap).

So that means the only educative files around now are for older data streams. If you want to make progress in your learning you'll be better off focusing on data streams using older encryption algorithms for which working tools are available.

[viewer]

Back in the Goldoic era.

Thanks gw1...I had a good belly laugh at that term....well done

Perhaps we are now in the " gammadroid" era now?

Sorry for hijack...I'm outta here...

[nihonjin]

very interesting read gw1. Thanks, its good to have you back posting in these parts of the forum.

[fasulye]

You will never be able to create your own .gam files without knowing the keys used to encrypt the actual 0201 commands. Remember in addition to the basic XOR checksum there is also a MAC (using the DES checksum algorithm) that needs to be calculated and included in the message. For this you need the Card IV.

Also the gamma team do not extract the required keys they way you describe it. Its done by first extracting the core set of keys from a real sub. No magic in that. It's done via micro-probing the card after exposing the die. Irdeto 2 does not use the same algorithm or key constructs as Irdeto 1.

Once the base set of keys are extracted they then log for activations in the stream. From this they generate the remaining keys and construct there own card. This is why the provider has stopped sending these.

This is why each sellers card has a different set of keys each time one is created. From the base set of keys they can create there own cards.

[gw1]

I've no interest in making gams but grokking is always nice. Thanks for the detail, it's been a while and I'd forgotten the half I knew

[tristen]

... grokking is always nice.)

Grokking ??

Well now! That's a new one for the not-so-literates (like me)!

For those who don't know, courtesy Wikipedia

Grok

For other uses, see Grok (disambiguation).

To grok (pronounced /ˈgrɒk/) is to share the same reality or line of thinking with another physical or conceptual entity. Author Robert A. Heinlein coined the term in his best-selling 1961 book Stranger in a Strange Land. In Heinlein's view of quantum theory, grokking is the intermingling of intelligence that necessarily affects both the observer and the observed.

The Oxford English Dictionary defines grok as "to understand intuitively or by empathy; to establish rapport with" and "to empathize or communicate sympathetically (with); also, to experience enjoyment." Other forms of the word include "groks" (present third person singular), "grokked" (past participle) and "grokking" (present participle).

In an ideological context, a grokked concept becomes part of the person who contributes to its evolution by improving the doctrine, perpetuating the myth, espousing the belief, adding detail to the social plan, refining the idea or proofing the theory.

(Sorry about the digression. I'm obviously "stuck for things to do").

Thank you GW1, for both an interesting read and enlarging my vocabulary.

[fasulye]

gw1 is definitely a word smith. I really enjoy reading his posts. The attention to detail and understandably self protectionism.

One good thing (if you can really call it that) from your experience is that you have developed great skills in ensuring you don't incriminate yourself of any wrong doing. The right balance between fact and incrimination.

Yet you still contribute which I thank you for that.

PS - I had to look up grokking just to make sure you weren't having a go at me

[fireeater]

If you're interested in how things work and are prepared to spend time and energy learning for learning's sake then good on you. You've made a good start and will find lots of interesting hidden puzzles to explore.

However a large number of people, the majority I think we can safely say, study these things only because they want to obtain Pay TV reception more cheaply. If there was a program they could download and run that would magically give it to them they wouldn't spend even ten minutes reading about card processor types, file types and formats, interfaces, programming protocols, emulators, master keys, session keys, EMMs and ECMs, provider ids, country codes and so on.

Irrespective of your country or what satellite or cable system you use, to view an encrypted program you would need
1. a card emulator program with cryptosystem-specific algorithm and keys necessary to negotiate access to the data stream (eg Irdeto, NDS, Seca, Nagravision)
2. a provider-specific set of keys for decrypting the DVB control words (because emulators are useless without valid keys)
3. tools for installing the above on your hardware (clone card or PC/receiver emulator)

No working emulator or key files for GAMMA are public at this time, and you're not likely to find working ones for GAMMA or its successors on public sites in future, at least not on the scale witnessed in previous generations. To understand why you need to appreciate how clone file distribution has evolved, because GAMMA distribution logistics are unlike that of previous generations of card cloning.

Back in the Goldoic era, emulator and key were sold together as a unit to pirate retailers (sellers) who sourced blank cards themselves, programmed and sold them individually or in dish+receiver+card packages. When keys changed customers returned to their resellers who needed to obtain a replacement file from their supplier - they couldn't make it themselves. Blanks and programmers were both easy to obtain, and sellers weren't hard to find either, so it was in sellers' interest to maintain secrecy. But clone card discovery was inevitable; identified keys were deactivated and potentially traceable back to the originator.

To avoid a single point of failure crackers began supplying key extraction tools separate to their emulators. These enabled sellers to use their own subscription cards, making the crackers less vulnerable and releasing sellers from dependence on them for updates. Sellers now had greater incentive to preserve security among their clients, plus a means of fixing customer cards if one of their accounts was busted. Eventually though both the emulator and key extraction method both would become public, at which point every customer saw the opportunity to earn money from selling, piracy exploded and radical countermeasures became necessary.

Irdeto 2 required a fast crypto coprocessor which necessitated the use of a newer, more powerful card that was harder to obtain. But rather than rely on scarcity of the new blanks to hinder unlicensed proliferation of their emulator by end users, the GAMMA developers used the card's strong crypto not just for emulation but for licence control of the emulator itself.

• They programmed the blank cards with the emulator (algorithm and cam negotiation keys specific to each provider), same as before
• They produced tools for key extraction, same as before, though these were more tightly controlled, initially distributed only to regional heads (far fewer in number than previous generation sellers)
• The emulator contained a loader allowing keys to be updated by sellers, same as before
• The extracted key files were encrypted, readable only by the card loader (some emulators of previous generation did this but most didn't)
• The emulator's loader also supported emulator/key updates to be applied, sent in encrypted form from the developer to the sellers. That the emulator file only existed in encrypted form was a new development - in previous generations it was unencrypted. Because of this encryption the file could only be written to blanks that already had the developer's own loader, preventing sellers or third parties from cloning it onto independently-sourced blanks. ie the only person having the card program in unencrypted form was the developer himself. The encryption also hindered providers' efforts to develop countermeasures targeting emulator imperfections, since without a binary to reverse they could only discover discrepancies by trial and error.
• The emulator was configured to mimic a benign memory card when initially distributed, to avoid problems if intercepted in transit by customs or thieves. To turn off the mimicry and enable normal operation the developers preloaded a "transport code" known only to the regional distributor and his sellers, who supplied it using special loader commands. The loader had provision to shut down permanently after repeated attempts with an incorrect code.
• The emulator had two modes. One was where it booted to the loader and issued its own arbitrary "GAMMA" ATR for administrative purposes (recognised by tools supplied to the distributors by the developer), handling commands for regional/provider key entry and emulator update. Another was where it booted to the provider ATR. But the emulator and the loader are just different functions of the same program - there is no GAMMA "operating system" to speak of apart from the alternative ATR and loader commands (known to old-timers as the monitor or bootstrap).

So that means the only educative files around now are for older data streams. If you want to make progress in your learning you'll be better off focusing on data streams using older encryption algorithms for which working tools are available.

very interesting and informative post. I managed to get the HSN but the gamma loader which I have is, for Austar.

is it possible to get the Gamma loaders for any Ird*to providers

[nikos_]

where can i find CARD IV guys?