Activate

Irdeto Details and MOSC Activation v11

by 007.4

I am not an expert in these matters, just a hobbyist who likes to learn. I have read the FAQs, the readme files and postings in the various forums and then amalgamated all this information to produce this document. It is evolving as I learn more. My experience is primarily with the German system . The procedures will be similar for other countrys' Irdeto systems. I am mainly interested in how the decryption process works. I have written this text because it would seem that no one with more knowledge than me has already done so!

Disclaimer

If you can purchase a subscription for these TV services in your country then the procedures described here, may well be illegal. This information is provided for educational purposes only and must not be used to get free TV. The author accepts no responsibility for this and you do so entirely at your own risk. There is also a small but unlikely risk that any card that you try to reprogram may be irreparably damaged. You have been warned.

I WILL NOT SUPPLY ANY SOFTWARE THAT COULD BE USED FOR ILLEGAL PURPOSES.

DO NOT ASK.

What you need.

A dbox or Nokia Mediamaster with Irdeto All-Cam or C-Cam (A Dutch Irdeto cam, a Beta-Research "Blue" cam or CI cam will not work for Premiere World C-cards. There are now commercial blocker/doublers available which allow the use of C-cards in O-cams and CI cams) ideally programmed with DVB 98 v80ES (Freeware) or DVB2000 beta 36 (Shareware - so pay Uli!). Other digital receivers with the appropriate Cam are OK but you will not be able to do serial logging. Later versions of DVB2000 are also fine but do not allow serial logging in "Blocker" mode unless the memory in the dbox is larger than standard.

You also need a Manufacturers (or Modified) Original Smart Card (MOSC), either virgin (not officially activated) or expired.

If you have an expired card you may also want to log data traffic to the card. This can be done by three methods:-

1. Season Interface inserted in the decoder's smart card slot and a logging program such as XS4U. You need to apply +5 volts to the interface.

You can also use an excellent new program called CARDCOM. This will give fully commented log files and more.

2. Serial connection by null modem cable dbox RS232 to PC RS232. Use a logging program such as MasterLog v2.7. This now allows logging of nearly all bouquets and sorts all the logged data.

3. Logging by SCSI cable is now possible. This allows a higher data transfer rate than a serial cable. I have not tried it.

To write new instructions on your card you will need a Smartmouse (or equivalent) interface with a 3.57MHz or 6 MHz oscillator and a program such as Cardmaster (Win95/98) [Cardmaster 1.0beta is the latest version - in English] or CDevil (Dos but works in a W95/8 Dos window for me) or CardWizard (6MHz Smartmouse only). In Cardmaster 0.7e you must save the com setting and osc. frequency and exit, then restart the program before "connecting". Do not press "Karten Reset (Card Reset)" as this causes a hang. Put the card in the slot first then press connect. You should see the card details read out. Next press "CRD Laden (Load CRD) " to load the *.crd you want to use. If it does not start automatically try pulling and re-inserting your card. This initiates a reset and starts the file. Do not pull and insert to much (you might go blind!) or worse still - kill the card. Removing the card before disconnecting with Cardmaster1.0b causes a hang.

Tron's (may he RIP) original Irdeto 98 programs Pro_01.exe and Pro_02.exe will only work in DOS at 6MHz. They have limited capability but are virtually idiot proof. These have now been superseded.

Alternatively if you have a Phoenix interface (6Mhz only) SMC v2.0a and ICard (Win95/98) seems to work with this - and not with the Smartmouse type. ICard (Phoenix at 6Mhz only) uses *.icp files and not the more commonly used *.crd files.

You will also need the latest Irdeto 98 commands or the latest *.crd files unless you can generate them yourself. See later.

The Basic Theory As I See It

For a card to give a clear picture it has to have three data strings written in it.

1. A Date Stamp. Each day a different (consecutive) two byte date code is transmitted to the card - e.g. 02 31.

2. Correct Channel ID. A two byte code such as FF FC or 00 05.

3. A correct plain Key. This is a nine byte hex string, the first byte of which is the key number.

e.g. Key 10 could be 10 BC 51 7A 74 95 50 3C 69. This is sent in and encrypted form to the card.

Each card has two Service Providers - Provider 00 and Provider 10. In most countries only one provider is active, usually Provider 00. Premiere World (Germany) is now mainly on Provider 10. Each provider gives each card a Provider ID (three bytes such as 16 96 67). The first two bytes are the group ID (there may be 256 decimal cards in this group) and the final byte identifies that individual card.

In an ECM (Entitlement Control Message- the 01 05 ..commands) three data strings are sent to each group of cards. [See full explantion later]. The date stamp and channel IDs are the same for all groups but the Keys are different for each group. Thus each provider ID (group) must have its own individual key. However, just to confuse you, there are some parallel (or clone) groups which use the same keys! You cannot change the provider ID without knowing the MasterKey (00) of the card. The only way to find out the masterkey is to make a log of the official "switch on" command, or hope someone else has done this for you. There are databases available on the web with many (nearly all?) the logged masterkeys

In a virgin card the provider IDs are set at 000100/000200 or 000300/000400 or 000500/000600 or 000700/000800 depending upon the country.

When the card is put in the decoder and activation is requested - sometimes this happens automatically - the service provider sends an activation string and one of two things can occur. The exact details are country dependant.

1. For a full subscription - a new MasterKey is written to the card and new ProvID is given. This allows subsequent operational key updates. The correct Channel IDs are also given.

2. For a trial subscription - the MasterKey is disabled (deleted?) and the provID remains the same or changes to FFFFFF. Operational keys are written along with Channel IDs. However, a timer is also set so these cards automatically deactivate after a fixed period.

The full subscription initiation command [28 0d] or [68 0d] is sent to the card along with the MasterKey 00 which is eight hex bytes and the new provID - three hex bytes. There is also a five byte digital signature which must be correct.

The "hole" in Irdeto's armour is that the first four bytes of the signature of any command can be found simply by asking the card for them! The fifth byte is searched for by the card writing programs - it increments through all 256 combinations - until the exact match is found.

However later versions of the smart cards (eg German 8000/9000 series) have tightened up on security. The first four bytes of the digital signature can no longer be read out. Now all five bytes have to be found. 256*256*256*256*256 = a very big number, and it would take about 20 years(?) to test all possible permutations.

SignHunter

Fortunately it is now possible to find the digital signatures for writing to the 8000/9000 series cards. This is done by using slightly amended crds (no macros) with a program called SignHunter or with ordinary crds using a program called SigPro. This is now available on the web (check the links). The most difficult part of using SignHunter is finding the correct delta value. I suspect this is some form of delay and its value seems to vary with the crd, the card used and the PC processor speed. Longer crd strings seem to be easier to make work than shorter ones. SigPro finds the delta quickly and automatically.

You need to use plain DOS and 6MHx Phoenix type programmer. I believe SignHunter / SigPro work by timing the response from the card for each byte of the signature in turn. The time taken to give a correct response is different from that of a wrong one.

EMM / ECM Nomenclature

There seems to be some confusion as to which commands are ECMs (Entitlement Control Messages) and which commands are EMMs (Entitlement Management Messages). Common usage of ECM meaning Electronic Counter Measure in Eurocrypt has lead to the EMMs in Irdeto been labelled ECMs. This is incorrect.

The EMMs are the 01 01 .... commands. These enable and disable channels/cards. The 01 05 ... commands are the ECMs. These contain the information for the decryption process.

Irdeto Commands and Nano Codes

Attached you should find a zipped file (CRDcmdsX.zip) containing a selection of Irdeto commands for you to learn and experiment with. Some of these can destroy a working card - so take care! Look at the *.crds in conjunction with the following explanations. Let me know if you find any new commands.

The Irdeto system complies with the ISO 7816 standard for packet structure and protocol, using 6 byte command headers of the form

CLA, INS, P1, P2, P3, Length

The first byte CLA is always 01. The second byte INS is the instruction. The third and fourth bytes (P1 and P2) are references. The fifth byte P3 usually designates the provider, 00 for Provider 00 and 01 for Provider 10 The sixth byte is the length of the following data string including the NANO codes and signature. There is also an extra checksum byte which is not included in this length..

INS 1 Command - EMM

01 01 00 00 00 xx : Initiates EMM Update information to the card. xx is the length

The next following five bytes of each EMM identify the card(s) to be addressed. They are normally one of the following

02 [Provider group of provider 00, (2 bytes) ] 00 00 - Use crd macro p0

03 [Provider ID of provider 00 , (3 bytes) ] 00 - Use crd macro p2

0A [Provider group of provider 10, (2 bytes) ]00 00 - Use crd macro p1

0B [Provider ID of provider 10 , (3 bytes) ] 00 - Use crd macro p3

C3 [Hex Serial Number, (3 bytes) ] 00 - Use crd macro s0

The sixth byte is always the length of the following string excluding checksum..

Examples of EMMs

1. This activates the Channel Id (ch id) for provider group (pg pg) of Provider 00 on date (dd dd) the signature is (ss ss ss ss ss) and the checksum (cs). The timer is set to FF 00.

01 01 00 00 00 17 02 pg pg 00 00 11 40 02 dd dd 11 06 ch id dd dd FF 00 ss ss ss ss ss cs

2. This writes Key 06 (k6) for Provider 10 on date (dd dd) for provider Id (pi pi pi)

01 01 00 00 00 1A 0B pi pi pi 00 14 40 02 dd dd 10 09 06 k6 k6 k6 k6 k6 k6 k6 k6 ss ss ss ss ss cs

If all the data is correct in an EMM and it is accepted, the card responds with a return code of just 3F. If there is an error the card rejects the EMM with a different return code.

The following are possible answers (return codes) to the 01 INS EMM commands.

01 01 00 00 3F : Command accepted

01 01 00 00 3F 00 00 03 00 00 00 : Signature OK but key no longer accepted? Provider 00

01 01 00 00 3F 00 00 03 00 00 01 : Signature OK but key no longer accepted? Provider 10

01 01 00 00 3F 00 00 03 00 40 00 : Signature OK but wrong date or no key? Provider 00

01 01 00 00 3F 00 00 03 00 40 01 : Signature OK but wrong date or no key? Provider 10

01 01 00 03 00 : Command not accepted, wrong signature
01 01 70 00 00 : Command not accepted, wrong Hex serial number

01 01 71 00 00 : Command not accepted, wrong Provider ID

01 01 72 00 00 : Command not accepted, wrong Provider Group

01 01 73 00 00 : Command not accepted, wrong Provider Group

01 01 74 00 00 : Command not accepted, wrong Provider ID (not in the CB 20 string)

01 01 76 00 00 : Command not accepted, wrong ???

01 01 78 00 00 : Command (not?) accepted, wrong ???

01 01 79 00 00 : Command accepted.

01 01 7A 00 00 : Command not accepted, wrong ???

01 01 7B 00 00 : Command not accepted, wrong Provider ID/Group/signature???

01 01 7C 00 00 : Command not accepted, wrong signature

01 01 7D 00 00 : Command not accepted, Masterkey missing

01 01 7E 00 00 : Command not accepted, wrong Provider Identifier Byte - should be 00 or 11

01 01 7F 00 00 : Command not accepted, invalid nano???

01 99 00 02 99 99 99 00 : Command not accepted, wrong address (c8/9k)??

Blockers work by preventing EMMs getting to the card. They only allow the following ECMs.

--------------------------------------------------------------------

INS 2 Commands - Get...

01 02 00 03 00 : Get Cards Serial Number in ASCII

01 02 01 03 00 : Get Cards Serial Number in HEX. The last byte is always 18h.

The sixth byte from the end indicates the number of providers on the card. Usually 02. But 01 and 03 have also been seen. 03 causes some problems for some receivers (UEC).

01 02 02 03 00 : Get Cards Country Code. Last three bytes (in ascii).

The first two bytes indicate the internal card version. ACS 1.2 cards are 02 01. C8/9k cards are 03 82 or 03 83.

01 02 03 03 00 : Get Provider ID 00

01 02 03 03 01 : Get Provider ID 10

01 02 04 00 00 01 [00....09] : Get ChanIDs, dates and timer for Provider 00

01 02 04 00 01 01 [00....01] : Get ChanIDs, dates and timer for Provider 10

01 02 07 00 00 20: Writes 32 bytes to buffer. If the length is set to zero this also enables reading of the buffer using...

01 02 08 00 00 00: Get 32 bytes from buffer. These commands only work on series < c8000 (PW) or < ACS 1.6

01 02 09 03 xx 40: Send CAM Key

01 02 0B 00 00 :Get Country code, 1st three bytes. Followed by 00 8c 00 64 00 14 00 00 00 00

Then manufactures code. eg B D T V x x x x x C. All characters in Ascii. The 64 and 14 indicate the maximum possible ChID positions for provider 00 and 10 respectively. Some cards have these set at 46 and 32. Thus the maximum number of ChIDs that can be stored is 78h= 120 decimal.

01 02 0D 00 00 : Get first four bytes of signature after an incorrect response

01 02 0E 02 00 : Read Card File 1

01 02 0E 03 00 : Read Card File 2

01 02 0F 00 00 : Get Ascii SN, ProvID for Provider 00 and 8 + 5 byte string.

The eight byte string always seems to be 42 98 2C 4D D9 EA F4 69. Even for Irdeto cards from different countries. I assume the 5 byte string is a digital signature.

01 02 0F 00 01 : Get Ascii SN, ProvID for Provider 10 and 8 + 5 byte string.

The eight byte string always seems to be F0 EC F2 80 85 AB 29 71.

01 02 0F 00 xx : Get Ascii SN, ProvID for Provider 10 and 8 + 5 byte string.

As xx increments, different 8 +5 byte strings are returned. ROM dump?? It is the same for all cards.

PIN Numbers

01 02 0A 0x xx xx Basic PIN number command.

There are four possible PIN numbers on a card. These are identified by the fifth byte of the PIN number command.

00 - Parental PIN

01 - IPPV PIN

02 - Home-Shopping PIN

03 - General PIN

The following examples use the parental PIN

01 02 0A 02 00 02 xx xx ; Enter PIN number, (reply 50 = correct, 51 = wrong)

If a correct reply is received the same command is sent again and if it is confirmed correct, the return code is then 5E.

01 02 0A 01 00 04 xx xx yy yy; Change PIN, x = old pin, y = new pin (reply 51 = wrong xx xx, 52 = OK)

The PIN number can be found by sending all possible 9999 codes sequentially until the return code is 50/5E and not 51.

This can be done in the Smart Card menu of DVB2000 or with simple DOS programs like Irdetpin.

Answers to the Class 2 Commands

00: OK

50: not OK

51:not OK

53:not OK

54: not OK

55: OK

56:not OK

57:not OK

67: The length is incorrect.

69: Command not allowed

6B: Wrong reference (byte 4+5)

6C:The card does not support the instruction class (byte 2?) ??

6D: The instruction code is not programmed or invalid (byte 3) ?

6E: The card does not support the instruction class (byte 2?)

6F: No precise diagnostic is given

-------------------------------------------------------------------

INS 3 Commands

01 03 xx xx xx xx

The return code to these commands appears to be different from the INS 01 commands.

These commands may only work on corrupted cards.

--------------------------------------------------------------------

INS 4 Commands Set...

01 04 00 00 00 14 3x 3x 3x 3x 3x 3x 3x 3x 3x 3x 43 36 35 31 30 36 41 20 20 20

Changes ascii serial no. to xxxx xxxx xxy This only works for defective cards without write protection. That is with all data FFFFFFF or 000000.

Change the 10 "x" to the new ascii serial number. Leave off the last "y", it is some form of checksum calculated by the card. Only if you enter the correct ascii SN (as printed on the card) is the last checksum byte correct.

If this string doesn't work swap the last bytes after the 43 to:-

//43 37 30 32 32 32 41 20 20 20 for ???

//43 36 33 39 30 36 41 20 20 20 for ???

//43 36 31 36 32 33 41 20 20 20 for ARE

//43 36 31 30 31 38 41 20 20 20 for ZAF

01 04 01 00 00 00: Activates write protection

Answer is 01 04 42 00 01

01 04 00 00 00 00: Asks card if it is "write protected".

Answer 01 04 40 - not protected.

Answer 01 04 41 - protected.

If you attempt to write a new Ascii SN to a write protected card, the return code is "41" - write protected. However the data is written into the buffer. The Ascii SN is not changed. Use DumpBuff0708.crd to read contents of the buffer.

"Write protection" has nothing to do with blocking EMMs. I believe it is to do with the basic BIOS of the card. Variable data such as keys, dates, channel IDs etc are written to the eeprom of the card and these parts are not protected.

--------------------------------------------------------------------

INS 5 Commands ECMs (Entitlement Control Message)

01 05 00 00 xx xx: Sends the channel ID, provider identifier, key number, date and the key to be decrypted.

--------------------------

Here follows a full description of the decryption process. Thanks to two anonymous contributers.

In the initial exchanges between the cam and the card, the cam sends the Cam Key with this command

Sending: IRD/Cam Key

01 02 09 03 xx 40

00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01

02 02 02 02 02 02 02 02 03 03 03 03 03 03 03 03

04 04 04 04 04 04 04 04 05 05 05 05 05 05 05 05

06 06 06 06 06 06 06 06 07 07 07 07 07 07 07 07

The xx = 00 to 07. The value of xx determines which of the eight byte strings the card is to use for the decryption process.

So in 01 02 09 03 00 40 bytes 00 to 07 are used (00 00 00 00 00 00 00 00)

01 02 09 03 01 40 bytes 08 to 15 are used (01 01 01 01 01 01 01 01)

01 02 09 03 02 40 bytes 16 to 23 etc..

However, in some systems xx is always 00 and only the first eight bytes are used. In these systems the 40h bytes of the cam key always seem to have the same value. In other systems (CI -cams and UEC decoders etc) the value of the cam key changes every time it is reset. Anyone know the algorithm for this. Is it pseudo-random or are there a set number of different cam keys?

If the card and the cam are all in order. Then the card accepts the key with:-

Card Accepting IRD/Cam Key

01 02 55 00 09 xx 00 00 6y

The 6y is the CRC byte (checksum).

If there is an error then the return from the card is:-

01 02 57 .....

and no decryption or picture can occur.

--------------------------------------------

Next an ECM is sent.

The first step is the Channel ID check. The card checks to see if the ChID in the ECM packet is in the ChID look-up table and has an active date. If the date has expired the card returns

01 05 93

If the ChID is not present the card returns
01 05 90

and the next packet is waited for and checked.

When the ChID is present the next step is the key decryption.
There are two possible modes depending upon whether the decryption is to use one key ( first key or the second key) or both keys in the ECM packet.

Example of an ECM packet

01 05 00 00 kt 23 Ch ID 10 kn 00 1D 40 02

dd dd 78 12 kn kp z1 z1

z1 z1 z1 z1 z1 z1 z2 z2

z2 z2 z2 z2 z2 z2 ss ss

ss ss ss cs

This breaks down to:-

01 05 00 00 kt 23 The ECM, length 23 hex bytes. kt indicates whether one (kt=00) or two (kt=02) keys are to be used.

Ch ID Channel ID

10 Provider 10

kn Key number (02, 04, 0c etc)

00 Always 00? Padding?

1D Length

40 02 Set date dd dd (could also be 00 02 ). Can be in different positions in the string.

78 12 The 78 nano and length

kn Key number again (02, 04, 0c etc)

kp Key packet. Always 12 or 13 in the German system but can be 00 or 01. Only the lowest bit is significant.

This determines whether the first (z1)or second eight bytes (z2) are to be used. If kt =2, both are used.

z1 z1 z1 z1 z1 z1 z1 z1 Eight bytes of encrypted key one

z2 z2 z2 z2 z2 z2 z2 z2 Eight bytes of encrypted key two

ss ss ss ss ss Digital signature

cs Checksum

Mode 1 - Both keys are to be used.

The first ECM for each ChID always has k t= 02

01 05 00 00 02 xx ( kt=02, therefore both eight byte keys are required).

If the decryption is successful the answer is

01 05 9D ......: The return of data including decrypted key and clear picture!

The packet will be something like:-

01 05 9D 00 38 01 02 16

ch ID 00 kt FF FF k1 k1 k1 k1 k1 k1 k1 k1 k2 k2

k2 k2 k2 k2 k2 k2 cs

kt = 2 so the reply is 16 bytes (k1 plus k2) where k1 and k2 are the decrypted keys of encrypted key z1 and z2 respectively.

Once the cam receives a 01 05 9D 00 reply (decoded) it then starts sending 01 05 00 00 00 strings.

(If kt=00 only one eight byte key is to be returned).

While ever there is no 9D reply it will keep on sending 01 05 00 00 02.

--------------------------

The card processes the encrypted key(s) using the plain session key of key number kn which is written on the card. The plain session keys are the same for all cards of the same bouquet. The algorithm for this decryption is not known (at least publically). Therefore it is not possible to emulate this process.

It involves the Cam Key, the date and the plain session key.

--------------------

Mode 2 - only one key is to be used.

The next ECM could be like this:-

01 05 00 00 00 26

ch ID 10 kn 00 20 40 02 dd dd 48 01 00 78 12 kn

kp z1 z1 z1 z1 z1 z1 z1 z1 z2 z2 z2 z2 z2 z2 z2

ss ss ss ss ss cs

kt = 00, therefore only one 8 byte key reply is necessary

If kp = 00 or 12, only z1 is used in the algorithm. Encrypted key z2 is ignored.

If kp = 01 or 13, only z2 is used in the algorithm. Encrypted key z1 is ignored.

The reply would be:-

01 05 9D 00 38 tt 00 0E

ch ID 10 kp FF FF k1 k1 k1 k1 k1 k1 k1 k1 cs

The reply of k1 is based on the values of z1 only (assuming kp was 00 or 12).

The tt in the reply always seems to be inverted from the kp in the key packet sent.

So if kp = 01 then tt = 00 or if kp = 00 then tt = 01

or in Europe

if kp = 13 then tt = 00 or if kp = 12 then tt = 01

The purpose of the 48 (01) nano is not known.

--------------------------------------------------------------------

If the decryption is not succesful the return codes are:-

01 05 90 00 00 : Channel ID missing

01 05 93 00 00 : Channel ID out of date

01 05 94 00 00 : ?

01 05 97 00 00 : ?

01 05 9C 00 00 : Masterkey Error

01 05 9E 00 00 : Wrong decrypted key

01 05 9F 00 00 : Key missing

01 05 A0 00 00 : Wrong Bouquet?

--------------------------------------------------------------------

Initial Cam / Card Exchanges

When the decoder is first switched on or the cam is reset there is an exchange of data between the cam and the card. The cam makes the requests and the card, the replys, as follows:-

Request : Country Code

01 02 02 03 00 00 3D

Reply : Country Code

01 02 00 00 02 03 00 10

02 01 99 17 01 17 02 17 03 17 04 07 41 44 45 55 (DEU)

Request : Cards ASCII Serial Number

01 02 00 03 00 00 3F

Reply : Cards ASCII Serial Number

01 02 00 00 00 03 00 14

3x 3x 3x 3x 3x 3x 3x 3x 3x 3x 43 36 34 32 30 33

41 20 20 20 30

Request : Cards HEX Serial Number

01 02 01 03 00 00 3E

Reply : Cards HEX Serial Number

01 02 00 00 01 03 00 10

00 17 00 00 01 00 17 00 00 01 02 00 xx xx xx 18

Request : Cards Provider ID 00

01 02 03 03 00 00 3C

Reply : Cards Provider ID 00

01 02 00 00 03 03 00 18

00 p0 p0 p0 00 00 00 00 00 00 03 12 00 00 00 00

00 00 00 00 00 00 00 00 36

Request : Cards Provider ID 10

01 02 03 03 01 00 3D

Reply : Cards Provider ID 10

01 02 00 00 03 03 01 18

11 p1 p1 p1 00 00 00 00 00 00 03 18 00 00 00 00

00 00 00 00 00 00 00 00 2B

Request : Cards HEX Serial Number

01 02 01 03 00 00 3E

Reply : Cards HEX Serial Number

01 02 00 00 01 03 00 10

00 17 00 00 01 00 17 00 00 01 02 00 xx xx xx 18

Request : Card File 1

01 02 0E 02 00 00 30

Reply : Card File 1

01 02 00 00 0E 02 00 40

D9 F9 0B 14 20 F1 AA 7D 0E 84 BE C2 FD E3 54 DE

F0 C8 FC BE B1 BA DD 43 78 68 45 99 07 7C 6B 6C

39 9A 07 E0 BC 35 E5 11 C3 01 9F 0D F1 C7 91 67

37 89 32 AB 44 65 CA AC B1 80 42 85 99 E7 21 C1

Request : Card File 2

01 02 0E 03 00 00 31

Reply : Card File 2

01 02 00 00 0E 03 00 40

3F 5E 10 0D EB 30 4B 05 22 5D DB CA FE 24 26 7E

CF 78 0C 69 D1 75 7A 67 84 1F 2C A6 75 F6 0F 59

1E E0 18 FE A8 71 DD 25 D6 3F 6B 4E 05 67 1E D7

76 41 03 1B 31 17 6D B0 F6 2E F6 8A 39 67 7B E6

Request : Country Code

01 02 02 03 00 00 3D

Reply : Country Code

01 02 00 00 02 03 00 10

02 01 99 17 01 17 02 17 03 17 04 07 41 44 45 55 (DEU)

Request : Cards HEX Serial Number

01 02 01 03 00 00 3E

Reply : Cards HEX Serial Number

01 02 00 00 01 03 00 10

00 17 00 00 01 00 17 00 00 01 02 00 xx xx xx 18

Sending: IRD/Cam Key

01 02 09 03 00 40

B4 3C 56 92 CB 91 89 1E 9C A2 F1 C5 DF A0 11 E8

7D AB BF 23 DB CF 82 0A 5D E1 52 0B 2E 26 5F FC

D1 83 07 7A 92 4A 43 05 4B 3B FA 30 4D C8 1C BB

C7 C8 9C 51 22 2E 86 14 A2 41 72 24 0F 00 D2 81

Card Accepting IRD/Cam Key

01 02 55 00 09 03 00 00 63

Request : Cards HEX Serial Number

01 02 01 03 00 00 3E

Reply : Cards HEX Serial Number

01 02 00 00 01 03 00 10

00 17 00 00 01 00 17 00 00 01 02 00 xx xx xx 18

Request : Cards HEX Serial Number

01 02 01 03 00 00 3E

Reply : Cards HEX Serial Number

01 02 00 00 01 03 00 10

00 17 00 00 01 00 17 00 00 01 02 00 xx xx xx 18

Request : Cards Provider ID 00

01 02 03 03 00 00 3C

Reply : Cards Provider ID 00

01 02 00 00 03 03 00 18

00 p0 p0 p0 00 00 00 00 00 00 03 12 00 00 00 00

00 00 00 00 00 00 00 00 36

Request : Cards Provider ID 10

01 02 03 03 01 00 3D

Reply : Cards Provider ID 10

01 02 00 00 03 03 01 18

11 p1 p1 p1 00 00 00 00 00 00 03 18 00 00 00 00

00 00 00 00 00 00 00 00 2B

Request : Cards HEX Serial Number

01 02 01 03 00 00 3E

Reply : Cards HEX Serial Number

01 02 00 00 01 03 00 10

00 17 00 00 01 00 17 00 00 01 02 00 xx xx xx 18

Sending: Key Packet

01 05 00 00 02 23

Ch ID 10 06 00 1D 78 12 06 12 B6 A7 75 3B 90 1C

00 DB AA 05 82 FF F9 3E C6 C9 40 02 03 18 0C DD

61 22 7A 1C

Reply : Key Packet / Decrypted

01 05 9D 00 38 00 02 16

Ch ID 00 12 FF FF 61 14 BE E6 60 FD 45 F6 BB 09

EA ED 79 58 82 25 78

You can see that most of the data is requested and sent more than once. The last byte of each reply packet is a checksum.

A decrypted key packet is repeatedly sent about every 10- 20 seconds. The same key packets can be sent consecutatively up to ten times, depending upon the Provider. Then they change.

Some decoders/firmware have a different set of initial exchange commands. Some (in particular the UEC) send a whole string of commands if the number of providers on the card is more than 02 (as determined by the HexSN string). Other cams will accept only a maximum of 04 providers.

--------------------------------------------------------------------

INS 6 Commands

01 06 xx xx xx xx

These only seem to work on corrupted cards.

--------------------------------------------------------------------

NANO CODES

These are two byte commands embedded in the EMMs. The first byte is the instruction. The second the length of the following string. It would seem that there are compatible nanos.

It is known that 11 (06), 51 (06) and 91 (06) all have the same function. Also there are other pairs eg for date 00 (02) or 40 (02) and new provider ID 28 (0d) and 68 (0d).

It would seem that most (all?) nanos have compatible counterparts that are 40h apart. Possibly four different versions.

For example I have found

1B, 5B, (9B not tested) and the known CB (20)

also

29, 69 and the known A9(02/0A) (E9 not tested) and others.

10 (09) Set Key [1st byte is the key number followed by eight bytes of the actual key].

10 (52) Set Multikey - TWO keys in the same command

10 (E4) Set Multikey - FOUR keys in the same command

Compatible nanos are the known 50 (xx) and 90 (xx) but also D0 (xx) seems to work too.

You may wonder why the Multikey length bytes 52h and E4h do not correspond to the actual length of the strings sent. The reason for this is that only the lower six bits are used. So the length byte must be "AND with 3Fh".

09h AND 3Fh =09h or 9 decimal (1 key identifier byte plus 1x eight key bytes)

and

52h AND 3Fh = 12h or 18 decimal (2 key identifier bytes plus 2x eight key bytes)

and

E4h AND 3Fh = 24h or 36 decimal (4 key identifier bytes plus 4x eight key bytes).

Also the high two bits can indicate the number of keys.

09h = 00001001 high bits 00 = 1 key

52h = 01010010 high bits 01 = 2 keys

E4h = 11100100 high bits 11 = 4 keys

------------------------------------

Example of MultiKey Update

01 01 00 00 00 3D 02 pg pg 00 00 37 40 02

dd dd 11 06 Ch ID dd dd

0A 00 10 E4 02 k2 k2 k2

k2 k2 k2 k2 k2 04 k4 k4

k4 k4 k4 k4 k4 k4 06 k6

k6 k6 k6 k6 k6 k6 k6 08

k8 k8 k8 k8 k8 k8 k8 k8

xx xx xx xx xx cs

01 01 00 00 00 3D EMM, length 3D

02 pg pg Address provider group pg pg

00 00 Filler

37 Length

40 02 Set date dd dd

11 06 Ch ID 0A 00 Address this channel ID, timer

10 E4 Multikey update NANO (sometimes 50 E4) and length

02 Key number

k2 k2 ........ Key 2

04 Key number

k4 k4........ Key 4

06 Key number

k6 k6....... Key 6

08 Key number

k8 k8....... Key 8

xx xx xx xx xx Digital signature

cs Checksum

Sometimes the keys are 0A, 0C, 0E and 10.

------------------------------------

11 (06) Activate Channel ID (2 bytes chanID, 2 bytes datestamp + 2 bytes timer)

Compatible nanos 51 (06) and 91 (06) D1 (06). If the two bytes for the date and for the timer are set to 00 00 00 00 this acts as a "kill" or switch off command. On some cards a date stamp of 00 00 is accepted.

--------------------------

28 (0D) Change ProvID (00/11 provider, 00 + eight bytes masterkey, 3 bytes new ProvID.) Used by German system.

This is followed by a 5 byte signature.

Compatible nano 68 (0D)

Example of New Provider ID

01 01 00 00 00 1A C3 hx hx hx 00 14 28 0D 11 00 mk mk mk mk mk mk mk mk pp pp pp xx xx xx xx xx

1A EMM, Length 1A

C3 Get Hex Serial number

hx Hex Serial number

00 Filler

14 Length

28 0D Change provider ID and length

11 Provider identifier (for provider 10)

00 Key number. 00 indicates it is the Masterkey

mk Masterkey

pp New Provider ID

xx Digital Signature

The decrypted masterkey can be read out using dumpbuff0708.crd. The decrypted masterkeys of all cards in the same provider group are the same.

--------------------------

40 (02) Set date (2 Bytes) Also compatible nano 00 (02) .

48 (01) Purpose not known

52 (06) Write 6 unknown Bytes (normally 00 00 00 00 00 00) between ProvID and date

54 (00) Erase all ChanID entries of addressed provider (sets all ChanIds, dates and timers to FFFFFF...)

Compatible nano 94 (00)

56 (02) Put two bytes after the date often (31 00 - German) or (0A 01- Italian). May be used as a Time Zone/ blocker.

56 (10) Writes sixteen bytes of 00. Used in the resetcard.crd. However, it would seem that this only acts like 56 (02).

58 (01) xx : Writes the last byte in the message to xx

59 (08) Writes an eight byte text message (decimal characters) to 01 02 0c string. Used for IPPV?

5a (0a) Writes a ten byte message. First two bytes to 01 02 0f (last eight bytes encrypted)? Used for IPPV?

5b (03) Writes three bytes? As a check to 59 (08)? Used for IPPV?

5f (xx) Can be used for writing new PINs

62 (03) Set the country code. Three ascii bytes. eg 47 45 52 is GER

78 (12) Key number + 12/13 + 16 Bytes (2 x 8 byte Keys to be decrypted) + signature. Used in 01 05 00 command.

95 (02) Used after the set date nano (40 02). Usually 01 E2. Purpose unknown.

98 (01) Write one byte. The penultimate byte in the answer string to "getProvID"

CB (20) Selects the card from the users in that provider group (32 dec Bytes or 256 users)

A9 (0a) Normally 00 00 00 00 00 00 00 00 00 10. Deletes the masterkey?

A9 (02) Normally 00 00. Switch off masterkey command.

When a virgin trial 300/400 or 700/800 card is put in the dbox and is activated, the initial string contains (after the keyon / IDon instructions) the A9 nano. Thus the masterkey on the card is disabled. This means that any new keys cannot be written to the card. The new key has to be decrypted by the masterkey. I suspect something similar occurs with the Italian cards. The return code to new key strings, after the initial activation string has been accepted, is always 7C (wrong signature).

The only way to activate these cards is to write the masterkey again.

It has been attempted to write two keys (with different dates) in one string to a virgin card.

01 01 00 00 00 29 0A pg pg 00 00 23 40 02 d1 d1 10 09 04 k4 k4 k4 k4 k4 k4 k4 k4 40 02 d2 d2 10 09 06 k6 k6 k6 k6 k6 k6 k6 k6 s1

It does not work. Only the key with the date previously set is written. If a date is not set, that is, it is left at FF FF, then neither key is written. The MK is disabled and the card becomes useless.

CRD Macros

In *.crd files you will see some macros. This is what they do:-

R0 - Initiate card reset. If the card is OK it replies with the ATR (Answer to Reset).

// - Ignore the rest of this line. Used for remarks.

P0 - Get Card's set Provider Group 00 and put it here in the crd (2 Bytes)

P1 - Get Card's set Provider Group 10 and put it here (2 Bytes)

P2 - Get Card's set Provider ID 00 and put it here (3 Bytes)

P3 - Get Card's set Provider ID 10 and put it here (3 Bytes)

S0 - Put the HEX serial number here (3 Bytes)

S1 - Put the 5 byte digital signature here and check the value of the final byte.

T0 - Put the date stamp of Provider 00 here (2 Bytes)

T1 - Put the date stamp of Provider 10 here (2 Bytes)

I0 - Opens an input window so that you can enter HEX data. The length of the data string must be correct.

Parameter Format: I0Text_can_be_written_here_without_spaces,_always_end_with_;

Writing your own CRD

To write your own CRD you have to emulate the EMM commands sent from the provider to YOUR card. You may need only one CRD for one instruction, such as activating one ChanID. Or you may need to write a new key as well. This could be in a second CRD or combined altogether with the first. All CRDs must have the following information:-

1. 01 01 00 00 00 xx (6 bytes) The EMM command initiation where xx is the total length of the following string.

2. Identification bytes of your card's Provider ID/Group/Hex SN - either written long hand or using one of the macros (see above) plus padding 00 (five bytes + 2nd length byte (to end of string )).

3. 40 20 dd dd (date NANO and date, you could use macro T0 or T1)

4. NANO command and data. eg for Chan ID activation :- 11 06 ch id 00 00 FF 00

or for new key 10 09 KN kx kx kx kx kx kx kx kx Where KN is the key number and kx is the eight bytes of the key.

5. The digital signature of 5 bytes or more easily the S1 macro to determine this.

The most difficult part is getting the two length bytes correct. Remember to use HEX and to count all the bytes of a macro.

eg S1 = 5 bytes and t0 = 2 bytes. The second length byte is always six less than the first.

Study some already written CRDs and you will see that it is not as difficult as it may first seem. It is probably easier to edit an existing CRD with a simple text editor and insert/replace your own data as required.

There are also utilities available which, if you input the correct information, will write the appropriate crd for you . See for example CRD Construction Kit v0.4, CRD-Maker V1.2, CardStudioV08 and MasterLog v2.5 (stuff). A utility called cRDcHANGER will convert a Cardmaster type crd to a form that is suitable for SignHunter.

The Activation Process

1. For Virgin Cards.

There are two basic methods.

a) Irdeto 98 Method

Connect your interface to the PC (usually com1). Start PC in DOS mode and run one of the Irdeto 98 batch files. This will write the correct channels IDs as used at the moment to your card using pro_01.exe for provider 00 and pro_02.exe for provider10. I am not sure if this method is still working with some providers.

b) *.crd Method

Connect interface and run Cardmaster, Cdevil or SMC v2.0a. Make sure correct com port and oscillator frequency (3.5 or 6MHz) is selected. Also check that all (if any) DIP switches on your interface are set correctly. Old versions of Cardmaster were very unstable so CDevil (DOS) is probably to be preferred. Cardmaster 1.0b seems to be more slightly more stable than the previous version.

Insert the card first then "Connect" . You should then get an ATR and the card details read out. Do not press "reset" as this usually causes a hang. With either system next select the *.crd file you wish to use. (crdv1.13.zip has the latest versions at the moment). Check for the latest versions. You must use a crd that is suitable for a virgin card. Run the file. It will take a few minutes as it goes through potentially 256 options for each checksum to find the last byte of the digital signature. CDevil beeps nicely when it is finished. Cardmaster states "done". Your card is ready:-))

2. Expired Trial Cards

On some providers simply reactivating the trial ChanID with the timer set to FF 00 is all that is needed. Unfortunatley this does not work with all providers. For example the Italian system.

3. For Expired Previously Activated Cards

These cards are better since the provIDs have been activated, therefore new keys are being sent for all or most channels and the MK is not disabled. The basic channels can be opened as above, but for some channels you need to make a log of the Key updates for YOUR provider group. I find the serial method the simplest but you do need to make a hardware modification to your dbox which involves soldering a wire to connect a pin on the card reader to a pin on the xp02 connector. This is very simple and there are photographs and instructions posted already. Fotos.zip. Or see the Logging FAQ on the UHF (Blade's) site.

There is a good read.me file with the MasterLog beta v2.7 logging program by "Seven of nine". He describes two methods of serial logging. You will need to experiment which serial logging method to use with which logging program. MasterLog allows both.

Some of the Logging programs will only work with the German package and not with packages from other countries since the sync. IDs are set at 8270/8240 or 8170/8070. Other packages may require different values. MasterLog allows selection of the correct sync.IDs.

If you do not have a Nokia you can also use the Season interface method and XS4U or CARDCOM.

Instead of logging you may now be able to get keys for some channels from databases posted on the Web. You may be lucky and find the update keys you require. You should also look for keys from "key compatible" groups. Lists of these groups have been posted.

It is possible to reactivate an FFFFFF card of the c8000/9000 series using SignHunter/SigPro but as the MK is disabled this will only work until the next major ECM. The procedure to do this is quite involved but logical. There is enough information in this document for you to work it out for yourself!

a) Serial Logging in Blocker Mode

In Blocker-Mode you can only log the Keys that are sent to your card-group. If you are lucky your card may be in a group which contains a "Dealer-Card" in it. So all of the needed keys can be logged! However, there are quite a lot of cards that can't get all the Keys because they are just not sent by the service provider.

With your card in the dbox switch to the channel of your choice. The Nosferatu menu needs to be configured thus:-

1. monitor_all_ecm

2. normal (with nosferatu the blocker is active)

3. BLK prot: off

5. IPPV Pin

9. -Log prm: on (for logging DF1 - provider 00)

A. -Log sec: on (for logging Premiere -provider 10)

If you do not know how to get into the Nosferatu menu you are going to need to do some research. The details are posted in quite a few places. I will not supply this information.

Some of the latest logging programs will automatically generate the appropriate *.crd files for you to run, as described above.

There is a logging function in the latest DVB2000 releases. Try menu,8,3,0 - monitor on. I have not been successful with it. I think it depends upon the memory installed in the dbox. Anybody know the correct configuration?

b) Serial Logging in Data Download/PID-Mode

In this mode you can log the keys for all Card-Group not only your own. Any version of DVB2000 can be used for this method. If you are using a "Nosferatu" version for MasterLog v2.1 the Nosferatu menu needs to be configured thus:-

1. -monitor_no_ecm

2. -normal

3. -BLK prot: off

5.-IPPV pin

9. -Log prm: Off

A. -Log sec: Off

The Data Download menu (menu, 6) should be set be set to:-

1 -Log PID 1000>PC (For other bouquets enter the EMM pin. This can be found in the cam info menu).

2 -Mode: entire

3 -Status: Stopped (Press 3 to start the data transfer -running )

4 -BIN (Some loggers work with HEX, so experiment).

5 -Normal

6 -Buffer: 20 (try the highest value here that allows continuous running)

Connect the null modem cable and start logging. Let it run for an hour or more until you get the keys you want . You will also need the Channel IDs and date stamp.

For other countries' bouquets when using other logging programs you will need a different Log Pid. You can get this by looking at the black cam menu 4 (cam info) when you are tuned to the channel of your choice. The EMM/ECM pids are shown at the bottom. Use the EMM value. If the EMM pid is 1FFF this means that the blocker is active (Nosferatu version only).

If you cannot generate your own *.crd files then you will have to put the data you have collected into ones that have already been written. You can always edit other *.crd files with a simple text editor replacing the relevant information. You need to set the date, load the new key and then the new channel ID(s).

Then for Provider 00 you could run:-

date00.crd

You will be prompted to enter the date (two hex bytes).

Next run

keyon00.crd - you will be prompted to enter the nine bytes of the key you have just logged. If the string length is rejected (by Cardmaster) try entering it again but finish with a semicolon (;) before pressing <enter>

Finally run

idon00.crd - for each channel ID you have logged. Input the two hex bytes when requested.

Repeat these three steps again using date10.crd, keyon10.crd and idon10.crd for the Provider 10 data.

It may be important that the activation date for the ChID is the same date as the key on the card.

When the date stamp or the update keys are changed you will lose these channels. Therefore you must use a software blocker - Nosferatu menu (2. Nosferatu 3.BLK prot: on) or a hardware blocker.

Your card is now ready:-))

MCSA

I have no experience of this system but Tahseen posted this:-

"There are Virgin MCSA cards those that have providers 000300/000500. These cards are 8 days trial cards. They become activated once inserted in the IRD for the first time. These cards have only one channel ID and it is ABDE and allows the user to watch all channels including C+H and Zee. The 000300 cards usually opens the MNW where the 000500 opens the MNE. You can not have both on a Virgin card. Also you can not add any other channel IDS.
Virgins takes accepts key updates only once when activated for the first time. After that they do not accept any new key updates.
If one tries to force a key update to the card it will seize to work after that. So do not do this. To extend the life of a Virgin past the 8 days trial period, just use the simple IDON00 crd to change the timer from 00 07 to 00 FE or 00 FF. It will continue to work after the trial period.

Now the other type is the Activated expired cards (Non-Virgins). Cards with provider00 not 000300/000500. On these cards you can activate any channel ID including the SPTK and the Future channels. It is like any other card except for a simple trick. They use Provider 10 codes for Provider 00.

When activating a channel ID for provider00 card one usually uses a command like this:

01 01 00 00 00 L1 02 P0 00 00 L2 40 02 T0 51 06 CC CC 00 00 FF 00 ...... S1

where L1 and L2 are the command Lengths and CC CC is the channel ID.

For MCSA Non-Virgins. Just change the 02 before the P0 (Provider00 Group) to 0A and when addressing a specific Provider00, substitute the 03 with 0B and you are in business.

There are new MCSA cards released. I haven't seen these yet, so I can not say anything about them.

I hope my post clarifies this matter.
Regards to all.

Tahseen"

No ATR?

If, after experimentation, you find that your card is dead - no ATR. It may be possible to revive it. Try rapidly inserting and removing you card into the interface (10 - 30 times) whilst a reset signal is being sent by one of the card writing programs. This MAY give you a working card again. [I use Cardmaster v 04 at 6MHz to do this, other use CDevil whilst pressing F1. Note this is also the way to KILL cards!!!!]

The latest version of CardWizzard 1038 has a re-animation function

However, more often than not, although you will get an ATR, all the data is set at 000000 or FFFFFF and your card will be useless for decryption. The ascii serial number is often 730. The card can still be used for some experimentation. For instance you can write the ASCII serial number again.

This has no useful purpose.

If you have killed your card I am always looking for some for experimentation. So do not bin it - please send it to me.

Warning

Be aware that new software and *.crd files are being released everyday. Try them at your own risk. There are some sad bastards about who delight in posting "Permanent Kill" files - do not use upd180199.crd for example. It changes the ProvIDs and Country Code and thereby ruins the card. Be careful with any crd which writes a new provider ID. Look out for the 28 0D or 68 0D nanos.

Reaktiv (di_pro) may or may not fix it. Works in DOS 6.xx on com 2 only.

"Kill Locutus" crd will permanently kill your card.

Also some versions of MOSC.exe contain a virus (20kb version, 16kb version is OK). Again, this may be a fake file (it will not change the bouquet on your card -only the chanIDs) as was the PIC Blocker code.

Resetcard.crd is only for Greek cards that do not work. Do not use on a working card.

300-400Key.crd is Resetcard.crd.

Ppv123.exe 76kb long, is a Trojan Horse virus which reads your hard disc and uploads it to website (according to Sarantos).

Links

Lot of sites have recently closed down or are not very active.

http://www.united-hacking-forces.com/html/german/index.html Blades site - lots of info. Not very active now.

http://www.thoic.com/ Hosts various sites. OZ forum

http://www.digitalsin.org/ Also has a Forum (Italian)

http://sat-digital-tv.provider.com.pl/starte.htm Polish site - In English

http://www.multipage.net/multi/ Dutch site -English and German.

http://www.irde.to/hgw/ Bishop & HGW (German)

http://satswiss.com/ SatSwiss Not very active ATM (Multi-lingual)

I WILL NOT SUPPLY ANY SOFTWARE THAT COULD BE USED FOR ILLEGAL PURPOSES.

SO DO NOT ASK. MOST OF THE SOFTWARE MENTIONED IN THIS PAPER IS AVAILABLE ON THESE SITES

If you have found this description useful and would like to show your appreciation I would be grateful for any donations of Irdeto cards (virgin or expired or even dead!) for further experimentation. I am now particularly interested in DEAD cards. Can anyone help please?

DSPC

Digital Pirate Smart Cards. I believe the supply of these has now dried up.

There is no specific information about DSPCs in this document mainly because I have just started investigating them! I would be grateful of any donations - working, expired or otherwise.

Please report any errors or omissions.

I have received lots of requests for help following the posting of this document. Please re-read it and make sure the answer to your question is not in here before asking. Please write in English only. I will NOT give specific instructions to individuals about activating their own cards.

If you translate this to another language make sure that I receive a credit. Make it clear that I will only respond (maybe) to queries in English

Cheers

007.4

0074@mail.usa.com

Please write in English only.

24.2.99 v1

28.2.99 v2

02.3.99 v2.1

10.3.99 v3

15.3.99 v4

20.4.99 v5

24.4.99 v6