Videoguard

[gessle]

Just for learning and educational purposes only,not decoding NDS!!!


First of all:
The card is always asked by the ICAM to receive or send information. The card never asks the ICAM to do anything! To do this the ICAM always sends a 5 byte long command packet header to the card.

Example: 48 INS P1 P2 P3

The first byte is always 48 (command class) followed by the instruction number. The last 3 bytes are the parameters. P1 and P2 are used differently and are often ignored. P3 is the length of the packet to be send or expected to receive. The cards first reply is the instruction number which is a vital value for the ICAM. These instruction numbers are possibly contained in a jumptable in the ICAMs source leading to a specific offset where processing continues.

The Answer To Reset (ATR):

3F 7F 13 25 03 40 B0 0B 69 4C 4A 50 C0 00 00 53 59 00 00 00

3F TS - "3F" indicates inverse convention ("3B" would be direct convention)
7F T0 - "7" (0111...) indicates TA1,TB1,TC1 will be sent "F" (...1111) indicated that 15 historical bytes will be send.
13 TA1
25 TB1
03 TC1
40 B0 0B 69 4C 4A 50 C0 00 00 53 59 00 00 00 the 15 historical bytes

1. On start up we get 48 52 00 00 14. This asks the card for 14h bytes.

>48 52 00 00 14
<52 card replies command for ICAM
<SN SN SN SN card SN (unique address)
<00 A status byte?
<01 19 11 00 0C 09 00 01 02 03 04 10 01 00 00 always the same?
<90 00 sw1/sw2


2. The next cmd is 48 58 00 00 35. This asks the card for 35h bytes.

>48 58 00 00 35
<58 card replies command for ICAM
<00 fuse byte (see below)
<01 09 60 always the same
<00 SN SN SN card SN (unique address)
<ff ff ff ff unknown
<00 SN SN three bytes of card number (shared address)
<00 ff ff ff 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 unknown
<00 xx xx xx was written with the 4e nano on activation
<47 42 52 "GBR" on British cards only
<00 01 00 00 unknown
<03 RC specific region code for local programming. See later under INS1C
<00 00 00 00 unknown
<90 00 sw1/sw2

The fuse byte indicates whether the card is a virgin or married or active or deactivated. The fuse byte is set during the intitial activation possibly with the 3d nano.
00 - Virgin
05 - Married/FTV only?
20 - Virgin/??
24 - Married/Deactivated?
25 - Married/Activated

3. The IRD then askes to send 09 bytes with 48 4C 00 00 09

>48 4C 00 00 09
<4C card replies command for ICAM
>IN IN IN IN IRD Serial Number
>02 00 00 D8 02 unknown
<90 20 correctly married

If the card belongs to this box it replies 90 20 (OK).
If the card does not belong to this box it replies 90 00 (Not OK).
If the card has the fuse byte set but is previously unmarried, this command writes the IRD number to the card, thereby completing the marriage (sw1/2 = 90 a1). If the card is deactivated and this command arrives the IRD Serial Number is written to the cards EEPROM too (sw1/2 = 90 20).
If the IRD number is set to 00 00 00 00 it will be accepted by any box. eg an engineer's card.
The card must receive the correct IRD number before it will give valid responses to ECMs and EMMs.

4. The card is then asked for 09 bytes with 48 2C 00 00 09.

>48 2C 00 00 09
<2C card replies command for ICAM
<00 00 convert to HEX and add then 8000h - this is your PIN
<XX XX 00 00 on active card: FF FF 00 00, on deactivated card: 00 00 00 00
<00 Parental Control Byte (PCB) - see below
<00 00 unknown
<90 20 sw1/sw2

IT can be changed the PIN using command 48 2e 80 00 09.

5. Next we have an often repeated cmd 48 5C 00 00 04. The ICAM asks the card for 04 bytes.

>48 5C 00 00 04
<5C card replies command for ICAM
<00 00 00 00 allways zero, except during the activation process
<90 20

The command flushes a buffer containing the 7E nano. So don't issue INS5C if you haven't allready asked for the key (issued INS54) after sending an ECM to the card. You would get a totally wrong key.

6. Next comes 48 1C 00 00 20. This asks the card for 20h bytes.

>48 1C 00 00 20
<1C card replies command for ICAM
<47 42 52 "GBR"(47 42 52)=British cards , "IRL"(49 52 4C)=Irish Card
<XX Region code (01=England, 02=Scotland, (04=Irland?), 08=Wales, 10=North Irland)
<00 00 00 00 00 00 00 00 00 00 00 00 00 00 unknown
<01 XX XX 00 00 00 00 X0 XX 00 08 00 03 RC was written with the 75 0F nano on intital activation, zero on virgin cards
<90 20 OK

The fourth byte XX is the Country Code.
Values seen 01, 02, 08, 10 and 1b. This byte is a specific country code related to the Postal Code.
01 is for all English postcodes.
02 is for Scottish postcodes AB, DD, DG, EH, FK, G, HS, IV, KY, KA, KW, ML, PA, PH, TD, ZE.
08 is for Welsh postcodes CF, CH, DY, HR, LL, LD, NP, SA, SY, WR.
10 is for Northern Ireland postcode - BT.

1b is associated with "Postal Code" "UKxx". Is this another region or class of card?

The "GBR XX" is sent with the 75_13 nano to specify a country. It is sent by addressing the card via it's postal code address.

03 RC is the Local Regional code. This is used for local BBC and ITV regional programming. It is written with 75 0f nano on initial activation.

03 01 is London
03 02 is Anglia
03 08 is Yorkshire
03 09 is Meridian,
03 0D is Tyne-Tees,
03 14 is Carlton Central etc.

Some postcodes that lie in marginal areas between terrestrial transmitters may get two or more local regional services.
Please supply your regional bytes and local ITV channel(s) received so we can make a complete list.

This 48_1c cmd is also sent following every channel change. It is a test of regional (country) and local entitlement.

---------------------------------------------
The Parental Control Byte (PCB)

The category of blocked programming is determined bitwise. Six bits are used. If a bit is set that category is available, if it is not set then that category is blocked.
00 = blocks all channels.

PCB; "11 1111" LSB
|| ||||- unclassified
|| |||-- universal
|| ||--- PG
|| |---- 12
||------ 15
|------- 18

PCB:- 1F = 18 programming is blocked, 2F = 15 programming is blocked
37 = 12 programming is blocked, 3B = PG programming is blocked
3D = universal programming is blocked,
3F = unrestricted - no programming is blocked.

Other sample combinations of blocked channels:-
39 = U+PG 0F = 15+18 07 = 12+15+18 03 = PG+12+15+18 01 = U+PG+12+15+18


The level of parental control is selected in the services/parental control menu. This along with the rating byte sent in the ECMs can be used by the subscriber to block un-wanted programming.
The PCB is set using the 48 2E 40 00 09 command.

------------------------------
The Rating Byte

The level of parental control is selected in the services/parental control menu. This along with the rating byte sent in the ECMs can be used by the subscriber to block un-wanted programming.

The Rating Byte which follows the 02 nano describes the type of programming content.

00 = not-encrypted ?
40 = encrypted (Universal)
41 = encrypted/ppv (Universal)
42 = encrypted/ppv (PG)
43 = encrypted/ppv (12)
44 = encrypted/ppv (15)
45 = encrypted/ppv (18)
51 = ppv (12)
52 = ppv (15)
53 = ppv (18)
80 = Information/announcement channels

=== to be continued ===

[gessle]

7. The ECM Next comes the major cmd. These are sent about every 7 seconds.
48 40 40 80 XX The packet length can vary depending upon the number of entitlements included.

The following is a full ECM packet logged with a DVB-s. You'll see that only the last part is actually passed on to the smartcard. The first part is processed by the ICAM:

80 70 54 00 00 01 0E 38 1A 23 C5 FF FF 32 50 01 20 01 00 00 EB 41 7E 12 00 00 00 00 00 00 00 00 7E CC A1 C2 5E B6 85 92 00 00 7F 12 76 68 2C CF 57 B6 41 F6 80 E4 86 8F 7B C5 C3 0D 92 44 09 10 10 00 01 38 1A 23 C5 CB 02 FF FF 02 80 67 08 70 7F 04 34 82 D6 A1 D8

80 70 packet separator, first byte alternates between 80 and 81.
54 length of the whole packet
00 00 01 allways the same
0E Header length
38 1A 23 C5 Date and Time (26.09.2001 04:30:10)
FF FF allways the same
32 50 9th and 10th byte of key returned by INS54
01 alternates between 01 and 11 (indicates Odd/Even CW in returned key?)
20 01 00 00 allways the same
EB Checksum (00+00+01+0E+38+1A+23+C5+FF+FF+32+50+01+20+01+00+0 0=EB)
41 length of the packet send to the SmartCard

The following bytes are passed on to the SmartCard:

48 40 00 00 41 generated instruction header from the ICAM
00 Dummy send by the ICAM too
7E_12 00 00 00 00 00 00 00 00 7E CC A1 C2 5E B6 85 92 00 00 - signature and key adjustment
7F_12 76 68 2C CF 57 B6 41 F6 80 E4 86 8F 7B C5 C3 0D 92 44 - signature and key adjustment - for future cards?
09 10 10 00 set key
01 38 1A 23 C5 Sets Date/Time (for exemple:26.09.2001 04:30:10)
CB_02 FF FF sets two bytes
02 80 Sets rating byte
67_08 70 7F 04 34 82 D6 A1 D8 signature

Answer to ECM
>48 54 00 00 0f
<54 ICAM Command
<F9 8E F5 D5 D1 1B 2A A6 Even or Odd Control Word (encrypted with IRD number on PayTV channels)
<32 50 bytes are compared to the bytes in ECM Header
<00 00 Always zero?
<40 Something to do with fuse byte
<03 03=decryption was successfull/04=decryption was not seccessfull?
<00 Always zero?
<90 20 Sw1/Sw2

Now let's concentrate on the parts send to the SmartCard

>48 40 40 80 46
<40 ICAM comand
>00 Dummy
>7e_12 7E nano
>00 00 00 00 00 00 00 00 Signature Adjustment Bytes
>56 ab cf 95 51 b7 0e a2 00 00 Key Adjustment Bytes (using simple XOR if rating byte 00 or 80)
>09 10 10 00 Select public key 10 and initialise ASIC
>01 36 14 93 ee 01 nano - load date and time
>02 00 02 nano - rating byte - program content
>03 00 10 00 03 nano - check channel entitlements
>03 b7 58 00 These list the packages that include this encrypted channel
>03 b7 59 00
>03 b7 5a 00
>03 b7 5b 00
>03 b7 57 00
>03 b7 23 00
>67_08 Signature nano
>b8 07 e5 40 e5 6a 9a 34 Digital signature calculate with key 10
<90 20 transmission ok
---------------

Channel 5
48 40 40 80 37 [40] 00 7e 12 00 00 00 00 00 00 00 00 4d 23 cb 4e 15
68 cd 6c 00 00 09 10 10 00 01 36 14 91 36 02 40
24 38_05 08 00 1a 00 1d 04 03 00 1d 00 67 08 7f 38_05 nano
f3 a9 99 b0 e5 5f f0 90 20

Same Channel 5 a few seconds later
48 40 40 80 37 [40] 00 7e 12 00 00 00 00 00 00 00 00 2a b2 7e 30 61
b0 bb 9b 00 00 09 10 10 00 01 36 14 91 3c 02 00
24 38_05 08 00 1a 00 1d 04 03 b7 65 00 67 08 eb
97 8f e9 6a 72 6b 64 90 20

Note: the last time byte has incremented and for some reason the entitlement bytes have changed?? This may be associated with a change in the rating byte??

The channel ID entitlement is the two bytes after the 03 nano. These two bytes must match the channel ID entitlement that is on the card. These entitlements can be seen with a 48_2a read card.
For a BBC card they are:-

00 1D xx Cx BBC 1 + 2, BBC Choice, BBC News 24, BBC Knowledge
B7 65 xx Cx Channel 5
B7 66 xx Cx Channel 4
B7 72 xx Dx ITV (Channel 3)
B7 73 xx Dx ?
The last two bytes vary depending upon the expiry date of the entitlement. The first date byte is the year and month. The second byte always has a high nibble of Ch or Dh. These nibbles overwrite the high nibble of the day byte sent in the entitlement update.
eg
Original channel entitlement
B7 73 3A C5
card receives this update cmd
41 B7 73 3A 1A
then this is written to the card
B7 73 3A DA

These are the entitlements that exist for Sky 1
b7 23 xx Cx
b7 57 xx Cx
b7 59 xx Cx
b7 5a xx Cx
b7 5b xx Cx
It looks like these channel IDs can change over time as expired cards which were open on this channel do not have these IDs.
--------
At certain times some ECMs are longer and appear to have two sets of key adjustment nanos. These use both nanos 7e_12 and 7f_12. They also have some additional nanos/flags.

>48 40 40 80 4e
<40 card replys command for ICAM
>00
>7e_12 7E nano
>00 00 00 00 00 00 00 00 Signature Adjustment Bytes
>56 62 6e 2f f9 fd c7 55 00 00 Key Adjustment Bytes
>7f_12 7E nano
>07 7e a6 fb d9 86 c5 27 Signature Adjustment Bytes - reserved for future cards?
>b2 ad d0 c3 69 65 ea 1d c4 99 Key Adjustment Bytes - reserved for future cards?
>09 10 10 00 initialise ASIC with public key 10
>01 39 01 ad 39 Set date and time
>CB 02 ff ff nano and data (always FF FF?)
>02 40 rating byte
>24 Flag, Close Filter
>38 03 08 00 18 nano and data (length can also be 05 or 07)
>25 Flip filter cmd from open to closed or vice versa
>03 00 1d CHID "00 1d" is required, set by 03 nano
>00
>67_08 signature nano
>9a 3d db 7f c2 12 c0 b2 signature
<90 20 transmission ok

---------------------------
Some PPV ECMs appear to have a different P1
>48 40 60 80 75
<40 card replys command for ICAM
>00
>7e 12 7E nano
>00 00 00 00 00 00 00 00 Signature Adjustment Bytes
>e0 44 ad bb e4 94 c5 bc 00 00 Key Adjustment Bytes (using simple XOR if rating byte 00 or 80)
>7f 12 7E nano
>26 56 e6 f9 6f 2e 90 49 Signature Adjustment Bytes - reserved for future cards?
>e8 54 75 b9 72 e2 35 cc 68 8b Key Adjustment Bytes - reserved for future cards?
>09 10 10 00 initialise ASIC with public key 10
>01 39 0a 81 6b Set date and time
>cb 02 ff ff nano and data (always FF FF?)
>02 52 rating byte
>03 5d 68 c0 PPV CHID "5d 68" must be active, or
>03 b7 f4 c0 PPV CHID "b7 f4" must be active, or
>03 b8 28 c0 PPV CHID "b8 28" must be active
>38_03 08 00 cc nano and data (length can also be 05 or 07)
>25 Flip filter cmd from open to closed or vice versa
>04 Flag, unknown propose
>4d_0e 5d 68 39 10 00 65 06 00 00 a3 e3 00 d9 e4 unknown, same as in PPV EMM
>4d_0e 5d 68 39 10 00 65 06 00 01 45 e3 01 b1 e4 unknown, same as in PPV EMM
>67 08 signature nano
>b6 b4 18 7c 9f 8c d1 28 signature
<90 a0

=== to be continued ===

[gessle]

8. The ICAM askes the card to decrypt the ECM:

>48 54 00 00 0F
<54 card replys command for ICAM
<43 2e ea 56 1c a4 9e ff f5 79 key
<00 00 legacy code from old cards
<40 card status identifier (eg card is active, not active etc)
<03 indecator, PPV or normal channel, correct decrypted (03) or not (04)
<00 nag display
<90 20 sw1/sw2

The status bytes seem to be:
90 01 or 90 21 - not OK
90 00 or 90 20 - OK

A ten byte encrypted CW (key) is generated by the card from ALL bytes from the 09 nano to the end of the signature (algo unknown - but certainly using the date and key 10). The first eight bytes of this key are then adjusted by the Key Adjustment Bytes in the 7e nano string, and returned to the cam as the ten bytes of the INS 54. For the FTV channels this adjustment is a simple XOR function (if the rating byte is 00 or 80?). For the encrypted channels the adjustment algo is not known. The 9th and 10th bytes of the returned key are not adjusted in either case as the last two bytes of the 7e nano payload seems to be always 00 00. If these two bytes are varied then the 9th and 10th bytes of the INS 54 return are also changed.
The ICAM is believed to create one DCWs (odd or even) from these returned 10 bytes and to pass that to the CSA chip.

9. The interesting EMMs 48_42. These are variable length 16h, 22h, 30h, 31h, 35h or 3Eh etc.

They can be addressed to all cards using public key 10 (sometimes using a post-code filter), a group of cards (using shared address/CUSTWP bitmap and group key 12), or to a single card using private key 14 and unique address.

EMM length 16h This seems to be used for setting the date and time.
>09 10 00 00 initialise ASIC with selected 10 (public key - all cards)
>01 36 15 91 1d Set date and time
>10 cc 33 10 nano and two data bytes that increment on each successive EMM
>67_08 Signature nano
>d8 2f 9a 8e 40 0b 3e 6a Digital signature (not neccessary for the included nanos)
<90 20


EMM length 30h
>09_10 00 00 initialise ASIC with selected 10 (public key - all cards)
>24 Flag, Close Filter
>38_09 postal code address nano
>06 Opens card filter if this is the post code.....
>48 52 33 20 20 35 51 41 "HR3 5QA" postal code
>6d_09 nano and length
>01 08 00 73 17 92 9f ff ff data - always the same?? This is found in the 48_78 string.
>6d_09 nano
>02 03 45 57 60 00 ff ff ff data - always the same??
>67_08 signature nano
>60 7f c9 6b dd f4 8c e6 signature


EMM length 31h. This EMM sets the Time Zone and Region Code
>09 10 00 00 initialise ASIC with selected 10 (public key - all cards)
>24 Flag, Close Filter
>38_09 postal code address nano
>06 Opens card filter if this is the post code.....
>4c 4e 32 20 20 34 50 5a "LN2 4PZ"
>19 00 Set time zone to 00 (GMT)
>75_13 Nano and length
>00 47 42 52 XX 00 00 00 00 00 00 00 00 00 00 00 00 00 00 GBR Region byte
>67_08
>59 16 84 78 a0 d5 ef 8a sig

EMM length 35h
>09 10 00 00 initialise ASIC with selected 10 (public key - all cards)
>24 Flag, Close Filter
>38 09 postal code address nano
>06 opens card filter if this is the post code.....
>4c 53 31 37 20 38 42 51 "LS17 8BQ"
>6e_07 6e_07 Nano
>06 01 01 01 01 20 08 data, unknown
>6e_07 6e_07 Nano
>07 01 01 01 01 8f 00 data, unknown
>6e_07 6e_07 Nano
>08 01 01 01 01 20 00 data, unknown
>67_08 signature nano
>7a ee 04 4c 88 66 db 0a signature

EMM length 3Eh
>09 10 00 00 initialise ASIC with selected 10 (public key - all cards)
>24 Flag, Close Filter
>38 09 postal code address nano
>06 Opens card filter if this is the post code.....
>47 4c 37 20 20 33 53 44 "GL7 3SD"
>6e_07 6e_07 Nano
>01 01 01 01 01 8f 00 data, unknown
>6e_07 6e_07 Nano
>02 01 01 01 01 8f 00 data, unknown
>6e_07 6e_07 Nano
>03 01 01 01 01 8f 00 data, unknown
>6e_07 6e_07 Nano
>05 01 01 01 01 8f 00 data, unknown
>67_08 signature nano
>e1 29 d2 77 3c 0d f3 11 signature

-----------
The following seems to be the activation of EMMs. Usually addressed to a Shared Address/CUSTWP bitmap.
These occur about every ten minutes. The channel entitlements seem to be activated one at a time. This explains why when a card is activated the channels do not all get switched on at the same time.

EMM addressed to SA/CUSTWP bitmap Expired Card
>48 42 00 00 3c
<42 card replies command for ICAM
>09 12 00 00 initialise ASIC with non-public (group) key 12
>33 33 nano
>00 SN SN 1st three bytes of SN (Shared Address)
>00 02 00 00 00 00 00 00 00 00 0c 00 00 00 02 80
>10 00 00 00 02 00 00 00 00 00 00 02 00 00 80 20 CUSTWP bitmap
>41 b7 21 38 06 Channel Entitlement update and expiry date
>C0 Flag, write entitlement update?
>25 Flip filter cmd from open to closed or vice versa
>42 b7 21 Delete Channel Entitlement
>67_08 signature nano
>97 d2 a5 bd df 5f e7 eb signature
<90 80 Not OK.


EMM addressed to SA/CUSTWP bitmap Valid Card
>48 42 00 00 3c
<42 card replies command for ICAM
>09 12 00 00 initialise ASIC with non-public (group) key 12
>33 33 nano
>00 SN SN 1st three bytes of SN
>00 00 22 00 00 06 02 30 84 40 02 00 00 00 10 00
>00 40 00 40 00 00 04 20 40 00 10 00 00 00 20 00 CUSTWP bitmap
>41 b7 77 38 0f Channel Entitlement update and expiry date
>c0 Flag, write entitlement update?
>25 Flip filter cmd from open to closed or vice versa
>42 b7 77 Delete Channel Entitlement
>67_08
>1a 56 57 00 de 40 64 74
<90 a0 Not OK. Not in valid bitmap.

Same Card ten minutes later:
>48 42 00 00 3c
<42 card replies command for ICAM
>09 12 00 00 initialise ASIC with non-public (group) key 12
>33 33 nano
>00 SN SN 1st three bytes of SN (Shared Address)
>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 CUSTWP bitmap (Only one card addressed)
>41 b8 2d 38 09 Another Channel Entitlement update and expiry date
>c0 Flag, write entitlement update?
>25 Flip filter cmd from open to closed or vice versa
>42 b8 2d Delete Channel Entitlement
>67_08 signature nano
>ae d2 35 47 a7 46 66 f0 signature
<90 a0 Not OK. Is not to be written to the card as not entitled.


A successful entitlement update:
>48 42 00 00 3c
<42 card replies command for ICAM
>09 12 00 00 initialise ASIC with non-public (group) key 12
>33 33 nano
>00 SN SN 1st three bytes of SN (Shared Address?)
>ff 7e 1f ec d8 3c 29 b9 c9 ab e9 a2 fc 58 cf 6d
>9d fd 1e 9c 2b ed 73 e4 e2 f6 34 cb 36 1f 7e 39 CUSTWP bitmap
>41 00 1d 38 1b BBC channel entitlement ID
>c0 Flag, write entitlement update?
>25 Flip filter cmd from open to closed or vice versa
>42 00 1d Delete Channel Entitlement
>67_08 signature nano
>e4 5c eb c7 64 2c 97 31 signature
<90 21 OK. Accepted

Another type of group update addresses the card by its shared address but uses the 32 nano without a CUSTWP bitmap. This is another way of updating a whole group of cards.

>48 42 00 00 15
<42
>09 12 00 00 Initialise ASIC with non-public (group) key 12
>32 Open filter for whole card group
>SN SN SN SN of card group
>42 b7 82 Delete Channel Entitlement
>67 08
>30 51 8c a7 eb 0a 32 c8
>90 a0 Not OK. Update not needed as Channel Entitlement did not exist?

The PPV EMMs seem to use INS46
>48 46 20 01 3E
<46 card replies command for ICAM
>1f 08 unknown
>09 10 00 00 initialise ASIC with selected 10 (public key - all cards)
>01 39 04 0c 70 Set date and time
>02 52 rating byte
>38_03 08 00 cc nano and data (length can also be 05 or 07)
>25 Flip filter cmd from open to closed or vice versa
>04 Flag, unknown
>4d_0e 1e 00 39 10 00 65 06 00 00 a3 e3 00 d9 e4 unknown, same as in PPV ECM
>4d_0e 1e 00 39 10 00 65 06 00 01 45 e3 01 b1 e4 unknown, same as in PPV ECM
>67_08 signature nano
>f1 54 d4 97 66 c3 7b 37 signature
<90 a0 Not OK

=== to be continued ===

[gessle]

The Bitmap algorithm

The Bitmap consits of 20 digits. Each digit consists of 8 bits. You will see that there are 256 Bits (FFh) in this Bitmap. Each bit represents a number to be present (1) or not present (0). If bit number 4 (04h) is set to 1 then 04h is present. If bit number 45 (2Dh) is set to 0 then 2Dh is not present. (Start counting from the left!)

The signature and key calculation process

First you send a so called ECM (Entitlement Control Message) to the card which is buffered in the memory of the card. Note that this message has to include the 02 nano to be a real ECM and to unlock key calculation process. Then you issue INS54 which actually starts the main calculation. Processing the 09 nano the ASIC (Application Specific Integrated Circut) is being initialised using the specified key. Then each byte following the inital 09 nano up to nano 67 is being crunched thought a secret signature algorithm. If it is just a verification routine or if the appropriate signature is generated and checked against the given signature following the 67(08) nano is unknown. There are no differences in calculation times trying a correct and a totaly wrong signature, so that could mean that it is just a verification routine. But not sure about that at all!
Many nanos are signature protected. They will not be executed by the card if you don't attach the correct signature to the message.
If the signature was correct and nano 02 was included in the message processing continues crunching each byte after the 09 nano (perhaps including the final signature itself) through the secret key algorithm which generates the final key returned by the card. If the ASIC is being reinitialized after the signature check is unknown. The 7E nano (not signature protected) plays an important role too. The first 8 byte are xored against the bytes following the 67(08) nano resulting in the final signature which the card tries to verify. The last ten bytes of the 7E nano are xored to the final key if the rating byte is 00 or 80? If not, the results are totally different. Then,these bytes could be included in the main calculation.

The signature calculation algorithm

The signature scheme seems to be a variant of Ong-Schnorr-Shamir (OSS).
Mathematically, this scheme works as follows:

Choose a large integer, n (need not know the factorization), and a random integer, k, k relatively prime to n.

Compute h: h = -k^-2 mod n = -(k^-1)^2 mod n

h is the public key, and k is the private key.

To sign a message, M, generate a random number, r, relatively prime to n.

Compute:
S1 = 1/2 * (M/r+r) mod n
S2 = k/2 * (M/r-r) mod n

The pair, S1 and S2 are the signature.
To verify a signature, verify that: S1^2 + h * S2^2 = M mod n

In the scheme of the Sky card, It believes the following:
h is on the card (in ROM). It is referenced in the encrypted ROM routines that verify the signature.
M is the first 8 bytes of the packet hash from A0-A7.
S2 is the 8-byte packet signature
S1 is generated by the ASIC on the card.
Encrypted ROM performs the verification function given above.

================================================== ===========================================
The keys

key 10 is the primary public key
key 11 is the seconday public key
key 12 is the primary group key
key 13 is the secondary group key
key 14 is the primary private key
key 15 is the secondary private key

public key: same on every card, so signature is valid for every card
group key: same on a group of 256 cards, signature is valid for any card in this group
private key: unique to every card, signature is valid for only one card, this is mainly used for activation

Note that nanos 31, 32 and 33 are used in these activation messages too. These are believed to stop processing if the serial number (or shared address) does not match. This gives an additonal protection because you don't know your own private key to calculate the valid signature.
=== to be continued ===

[osn]

hello
can i contact with you by any how
answer me as fast as you can
thanks

[a3639]

This is great! Just what I was looking for

[wonderman]

Bravo, that's what i AM seeking for, Thanks for your information, it is very informative, where can I buy it?

[val]

What do you buy? No offtopic post, please!