SECA Instructions & Nano Commands
This document has been written solely for educational purposes.
The author accepts no responsibility for any illegal use of this document.
You therefore agree that you use this document and its associated attachments entirely at your own risk.
Menu:
Acknowledgments: Menu Roland von Gilead & Homealone INS 0x02 & INS 0x04 Menu Ins 02: output encrypted data with ins 04 Ins 04: encrypt data with key F Ins 04: encrypt data (len must be 8) with key F (ins 02 read encr data) C1 04 xP zK 08 dd dd dd dd dd dd dd dd Ins 04: encrypt data (len must be 8) with key F (ins 02 read encr data) C1 04 xP zK 08 dd dd dd dd dd dd dd dd The intention of this instruction is not known. Between 8 bytes of data like answer to the INS 0x04, that precedes it (to see down). C1 04 P1 00 08 P1 specifies to the provider, P2 does not serve. INS 0x04 Menu The intention of this instruction is not known. De-encrypt 8 bytes of data with the provider key 0x0F, that is to be in the card. To these data them 0x02 can be called with the INS (to see above). C1 02 P1 0F 08 xx xx xx xx xx xx xx xx P1 specifies the provider, P2 must point at 8 key 0F. * xx = transferred bytes. INS 0x06 Menu Ins 06: output a random word (8 bytes)ins with ATR 2 protection Nanocommand 87: set provider data for ins 44 (stored in 2b-2ch)87 (8 data bytes): ins 06 word Previous ins must be 06, data must be the same of ins 06 The intention of this instruction and the related ones to her are not known. 0x06 is due to maintain sequence INS > INS 0x40 Nano 0x87 > INS 0x44 > INS 0x42 or INS 0x8A. This instruction gives 8 always-different bytes and with them it initialises mF0E, that is the requirement for the INS 0x40 Nano 0x87. This single instruction this available one in the low way of programming. C1 06 00 00 08 P1 and P2 do not have meaning here. INS 0x0A Menu Ins 0A: output micro type, ROM checksum and card version bytes: 44h We can use this instruction to ask for to the card the version of software of its operating system and the BIOS. Canal + provides the software of the card (independently of the provider). The following versions exist: INS 0x0C Menu Ins 0C: initialisation commands P2 = 0 change serial number P2 = 1 init SECA P2 = 3 change mode (from level 3 to level 1) P2 = 4 change mode (from level 3 to level 2) and delete [8020-22][8028-8047] This instruction allows the personalisation of the card. The single function this available one in high way of programming, reason why the bit of Test m080,7 must be active. The possible functions are: C1 0C 00 00 08 xx xx yy yy yy yy yy yy It updates the EEPROM with EFF4, it writes 2 bytes (meant stranger) as well as 6 bytes of new series. P1 = 00, P2 = 00 xx xx = 2 Bytes, unknown meaning 6 * yy = new nro. of series of the card C1 0C 00 01 16 23 pp pp 90 KI kk kk kk kk kk kk kk kk 82 SIG Considerations: Parameter 1 has to contain to the Nano 0x23 and parameter 4 has to contain to the nano 0x90. Will be used the key of system stored in E010-E017, after de-encrypt the 8 proportionate bytes and once checked the company/signature. At least, this is thus for the Num30: CD 8D D3 81 2F 72 6D C7. It is assumed that the key is different based on the bios from the card. If the company/signature is correct, then the provider given in the card is created and the primary key with keyindex is written provided in a registry 8X. P1 = 00, P2 = 01 (flock 3984 Bytes of registries + providers) Nano 0x23 pp pp = Provider, if he is DRY then goes to 00 00 KI = Index of key 8 * kk = Key Nano 0x82 SIG = 8 Bytes of company/signature C1 0C 00 03 00 Copy 4 bytes of 7F53-7F56 (ATR 0E 6C B6 D6) in the EEPROM from EFFC-EFFF. This instruction activates, therefore, in the high way of programming from the normal way (the other way around it does not work). P1 = 00, P2 = 03. C1 0C 00 04 00 Copy 4 bytes from 7F57-7F5A (ATR 9B 1B C2 A3) in the EEPROM from EFFC-EFFF. Programming activates in high way from the way under (it does not work the other way around). Something of ambiguity still exists on the sense of the low way of programming. Perhaps the card is sold in one or another way of operation based on the necessities of the client (TV provider). The INS0x44 only, that is said, been available in way under programming (LPM) and apparently contains an alternative procedure EMM. INS 0x0E Menu Ins 0E: output serial number of the card Deco uses this function to request I number of series of the card. This I number of series is codified in the card in form decimal. It always has the format: 123.456.789 C1 0E 00 00 08 Example: Instruction to the card: C1 0E 00 00 08 Answer of the card: 0E 00 00 00 00 00 12 34 56 90 00 The six bytes 00 00 00 12 34 56 (UA [Unique Address]. They contain the serial number in hexadecimal format. We can pass to decimal using the computer of Windows in scientific way. We obtain the data: 1193046. We read it in format: 001,193,046, filling up the block from the right. There we have ours of series. The length of the answer chain is always 8 bytes. P1 and P2 are always 00. Both first bytes of the answer chain are not known. INS 0x12 Menu Ins 12: output provider id-string and regional bitmap C1 12 xx 00 19 This instruction uses deco to request identification data of DROUGHT like the channel provider. Examples of providers are Canal Satellite, Canal Spain and Canal NL. C1 12 P1 00 19 As we already must know, P1 and P2 take values from 4 bytes in each case: the four first contain I number of key of the provider, whereas the four last ones contain bitmap with additional information. Here, P1 can take values from 00 to 0F. If P1=00, requests information on DROUGHT. If P1=01.0F (Requests information of up to 15 possible providers, for the values that can be requested, to see the instruction 0x16. P2 always is 00). Example: [It requests information of SECA] Instruction to the card: C1 12 00 00 19 Answer of the card: 12 00 00 53 45 43 41 20 20 20 20 20 20 20 20 20 20 20 20 00 00 00 00 00 00 00 90 00 Example 12 xx xx 53 45 43 41 20 20 20 20 20 20 20 20 20 20 20 20 yy yy yy yy zz zz rr 90 00 Both xx xx contain YOU GO of the provider if these are 00 00 it identifies DRY. The bytes in 53 45 43 41 contain the provider indicative (Channel Provider YOU GO String), in format ASCII. In order to read them, first a decimal and it comes since we did above for the version of software. Chain ASCII is obtained SECA., that agrees with P1=00. are had 16 bytes to the designation of the providers. yy yy yy yy contains PPUA (Programme Provider User Address) and it is always made up of 4 bytes (with DROUGHT 4*00). The PPUA is made up of two parts: the first 4 bytes are the SA (Shared Address), which it follows UCScTcWcP-cByte (Customer Word Pointer). By means of the SA they are possible to be up to 256 cards, the CustWP will exactly identify a card of this group by means of bitmap of 32 bytes (CB20 corresponds with IRDETO Zz zz contains the date of installment aim (to see: date format). The length of the answer chain is of 25 bytes. The byte rr after the date contains bitmap regional Example: [Information of provider 1 is requested] Instruction to the card: C1 12 01 00 19 Answer of the card: 12 00 04 43 41 4E 41 4C 53 41 54 45 4C 4C 49 54 45 20 20 00 1A 0C 34 0E FF 00 90 00 Data of Provider I number 01: Provider ID/Ident: 00 04 Channel Provider ID String: "CANALSATELLITE" PPUA: 00 1A 0C 34 Aim of instalment: 0E FF Bitmap regional: 00 Some YOU GO of provider of example: 0000 SECA 0003 CANAL+ 0004 CANALSATELLITE 000C CANALSATÈLITE 000F ABSAT 0019 CANAL DIGITAAL Note: The correspondences with the table of transponders of infosat. They do not have why to be the present ones. The positions of the Ident are specific of transponder, not of the channel. Based on the distribution, a provider can have several Idents. INS 0x16 Menu Ins 16: output provider’s bitmap, pin prot status and flags C1 16 00 00 06 answer: 00 00 xx xx aa bb xx xx: providers bitmap aa: pin protection status (0=inactive 1=active) bb: flags bit 0 - addressable bit 01 (20.1) bit 1 - addressable bit 06 (20.6) bit 2 - addressable bit 07 (20.7) bit 3 - addressable bit 03 (20.3) bit 4 - addressable bit 05 (20.5) bit 5 - addressable bit 02 (20.2) bit 6 - addressable bit 00 (20.0) bit 7 - addressable bit 08 (21.0) With this instruction deco determines the number of providers in the card as well as if DRY he is available in the same one. Also they will be given: 2 Bytes of unknown meaning, the state PIN, as well as the present value of the registries m080. P1 and P2 always goes to 00. C1 16 00 00 06 Example: Instruction to the card: C1 16 00 00 06 Answer of the card: 16 00 00 00 03 00 CF 90 00 The meaning of the first two bytes (00 00) is not known. 2 bytes with the number of the provider are followed (emphasised, to see above), a byte of state PIN (00 = off), the last byte shows to the present value of the registries m080 (based on the active bits, 11001111 example CF = = Bits 7, 6, 3, 2, 1, 0 assets, Bits 5, 4 non active ones). Bytes 3 and 4 of the answer of the card indicate the number of providers. These two bytes in hexadecimal give a word of 16 bits. Again, we entered the computer of Windows, scientific way. We passed the amount 00 03 (that stays as 3 when entering it) of hexadecimal to binary. We obtain: 2 bits (a word of 2bits). Or, with example 2, we introduce the numbers hex 01 FF (that is as 1FF) and we passed them to bits. We obtain 9 bits (a word of 9 bits). In example 1, we found in the DRY card and a provider (1bit + 1 bit). In example 2, 8 providers in the card exist DRY and (1bit + 8bits). With the second bit of example one or ninth of example 2, the software of deco knows that, for example, to call to the instruction 0x12 (request for information of the provider), it is necessary to give to P1 a value him 00,,01 or between 00..08. The length of the chain of answer of is 6 bytes. By the way, a byte (8bits) is the meeting of two nibbles. An example: in the byte 0x82, the superior nibble is 8 and inferior the 2. INS 0x1A Menu Ins 1A: output primary keys index for given provider C1 1A xx 00 LEN aa aa bb bb cc keys index aa aa: maximum space for provider and flags (FF FF for seca) bb bb: remaining bytes free for provider (total bytes free for seca) cc: nano 24 flag (00 or FF) or pin protection status (for seca) With this instruction we can know what key primary can find a provider in the card. C1 1A P1 00 LEN P1 specifies the provider for which we want to determine what key indices have occupied, that is to say, what key has stored in the card. P2 goes to 00. The length of the answer is of 21 bytes. If there is no occupied index it represents with FF. Example: [The indices of key for provider 3 are ***reflxed mng] Instruction to the card: C1 1A 03 00 15 Answer of the card: 1A FF FF 0C 84 00 51 5C 5D 5E 50 [11*FF] 90 00 The first 2 bytes (here: FF FF) indicate that there is stored a structure of provider with a displacement of 0x19. Bytes both emphasised seem to indicate whichever bytes available for registries (that is to say, they are not occupied) still are in the card. The following byte (here 00) what there is in the displacement 0x1B of the structure of providers: Locked/Unlocked (to see INS 0x40, Nanos 0x01/0x02/0x24). Next a maximum of 16 bytes is followed each one of which they represent the primary indices of key: Are therefore the following indices of key provider 3: 50, 51, 5C, 5D, 5E in the card. INS 0x30 Menu Ins 30: pin transactions C1 30 00 00 10 (old pin)(new pin): insert/modify pin C1 30 00 01 09 (pin)(protection status 0/1): modify pin protection status C1 30 00 02 09 (pin)(flags): modify flags (6 bit) bit 0 - addressable bit 01 (20.1 not used) bit 1 - addressable bit 06 (20.6 override parental control protection) bit 2 - addressable bit 07 (20.7 ppv management) bit 3 - addressable bit 03 (20.3 ppv special management) bit 6 - addressable bit 00 (20.0 ppv management) bit 7 - addressable bit 08 (21.0 instruction protected flag) P2 = 0 insert/modify pin P2 = 1 modify pin protection status P2 = 2 modify flags (6 bits) The DRY system protects some transactions with a code PIN so that only them it can make the subscriber. These are made by means of the instruction 0x30. P1 always goes to 00. C1 30 00 00 10 If the subscriber wants to enter or modifying the PIN, deco will use this instruction. Also before the purchase of events PPV the PN can be solicited to verify the authorisation. P2=00 Example: Instruction to the card: C1 30 00 00 10 Data: 00 00 00 00 00 00 xx xx 00 00 00 00 00 00 yy yy xx xx it defines the stored PIN yy yy it defines the wished PIN Data: 00 00 00 00 00 00 AB 0F 00 00 00 00 00 00 AB CD Echo of the card: 30 00 00 00 00 00 00 AB 0F 00 00 00 00 00 00 AB CD 90 10 The bytes of state 90 10 indicate in this case an error: the given PIN does not correspond with the stored one. A correct exit would give the bytes of state 90 00. The length of the chain of commandos is of 16 bytes. INS 0x32 Menu Ins 32: output data requested with ins 34 Ins 34: data for ins 32 len must be 03 C1 34 00 00 03 d1 d2 d3 on exit: 29h = d1 2Dh = d2 2Eh = d3 Ins 32: output data requested data from ins 34 d1 = 29h d2 = 2Dh d3 = 2Eh d1 d2 d3 0 0 0 Provider package bitmap record C1 32 xx 00 0A 83 data 04 1 0 0 Provider PPV credits record C1 32 xx 00 0A 84 data 04 3 x x Provider PPV event record C1 32 xx 00 0D B1 data 04 4 0 x Seca record C1 32 00 00 0D B1 data 04 6 x x Given record (number) C1 32 xx 00 12 D2 data 03 With this instruction 0x34 with the appropriate commando is called to the data specified by the instruction. Here the denominated Registries enter game. In the area of memory of the card data exist that can be described like individual elements. An important part of the area of memory of the card dedicates to the creation and selection of these registries, which have a certain type as well as well as they have assigned to a provider or a DROUGHT. In a DRY card v4.0 a maximum of 329 registries can be created. The sequence of such is not certain and can vary of card. From the direction $$E040 we have 0x24 reserved for DROUGHT, them follow 0x1C bytes to him for each provider (therefore from $$E064), the rest until $$EFF4 is dedicated to manipulation of registries. The memory management is dynamic, and whatever fewer providers exist, more space for the creation of registries we have. 0x32 always accompanies 0x34. Let us remember that we spoke of the pair of instructions 0x34&0x32. That after an instruction 0x34 several can be sent to the card 0x32 if the last nano of the answer of the card is 0x03 (more information available). In another case, we obtain the nano 0x04 (no longer there is more information available). This is quite useful to read all the registries of a card. The answer chains have variable length, depending on the size and length of the transmitted registries. If more bytes of those are requested than the card it must transmit then the rest of the chain fills up with FF from 0x04. These do not have any utility. The Maximum length is of 89 (0x59) bytes in a V 3,0, equal the Maximum length of an exit chain. P1 contains the number of provider, 00 means here DRY. P2 always is 00. C1 32 P1 00 LEN The following nanos can be applied with 0x32: Command Nano Utility 0x00 0x83 they follow bitmaps of package (none for 00, DRY provider) 0x01 0x84 they follow credit registries (none for 00 DROUGHT) 0x03 0xB1 they follow registries PPV 0x04 0xB2 they follow registries DRY, are variations in this (To see: selection of any registry) 0x06 0xD2 it follows any registry. In the area of data it is given I number of registry starting off of the read one (begins in 00 01) 0x03 there are more data available. 0x04 no longer there are more data available. We are going to see the structure of a registry with an example INS 0x34 Menu Ins 34: data request We are going to comment the pair of instructions 0x34&0x32. If 0x32 is a general request instruction on watch, with 0x34 we predetermined that data assume we are going to transmit. The instruction 0x34 always proceeds to 0x32. C1 34 00 00 03 In the definition of the data to use, always the first byte is the commando and the following bytes are the part of data. (PPV = payment by vision). 00 00 00 Registry of package of bitmap of provider 01 00 00 Registry of credit of provider PPV 03 xx xx Registries PPV of provider 04 00 yy Registries DRY 04 00 00 Registry of PPV DRIES 04 00 01 Registry of DRY beginning 04 00 02 Registry of DRY activation 06 zz zz random Registries xx xx xx xx Continue the PPV-EventID, that identifies a transmission PPV of univocal form; yy gives the type of the selections registries DRY (to see: reading of arbitrary registries); zz zz is the record number (counting from 00 01), from as the reading would have to begin Example: Instruction to the card: C1 34 00 00 03 Command: 04 00 01 Echo of the card: 34 04 00 01 90 00 The commando with ampler part of data falls within the field instruction. First the instruction is sent then. P1 and P2 are always 00. The chain of instructions has a length of 3 bytes. It is possible to be found the definition of Registries and packages of bitmaps in the section of the INS 0x32 INS 0x36 Menu Ins 36: output data requested with ins 38 and PPV event recording Ins 36: output data requested and PPV event recording P1: bit 5 must be set - provider must be the same of ins 38 P2: key for signature and for superencryption (if bit 7 is set) data from ins 38 29h=d1 2Dh=d2 2Eh=d3 2Fh=d4 30h=d5 87-8Eh=a1..a8 d1 d2 d3 0 0 0 Provider package bitmap record C1 36 xx yy 1D && 83 data 04 $$ 1 0 0 Provider PPV credits record C1 36 xx yy 1D && 84 data 04 $$ 3 x x Provider PPV event record C1 36 xx yy 20 && B1 data 04 $$ 4 0 x Seca record C1 36 20 yy 20 && B1 data 04 $$ 6 x x Given record (number) C1 36 xx yy 25 && D2 data 03 $$ where: && = 86 a1..a8 if no probs or FF a1..a8 if key problems $$ = 82 (signature) if no probs or nothing if key problems The exact meaning of this instruction is not known, although associate goes to the PPV. First 0x38 is had to execute a INS or a combination of INS 0x34/0x32. C1 36 P1 P2 1D Bit 5 of P1 will go active (0x20), nibble under P1 = m10F. m10F is P1 in the INS 0x34/0x32-preceding 0x38 or INS. P2 contains the key. The part of data can be superencryption, then P2 will be of type 8X. To see down in the section of the INS 0x38, the explanations of the registered nanos of the INS 0x38. 1. Example: Instruction to the card: C1 38 00 00 1A 38 16 00 2A 00 00 2B 00 00 86 11 22 33 44 55 66 77 88 82 BA E1 BA BD FC 71 65 AB 90 00 Instruction to the card: C1 36 20 00 1D Answer of the card: 36 1C 86 11 22 33 44 55 66 77 88 83 00 00 00 00 00 00 00 00 04 82 8B 75 1F 10 9C 77 62 2D 90 00 Single I have investigated the chains of return for ww=00 and ww=01. Perhaps the Nano 0x36 repeats the transferred data, the Nano0x83 appears for a reason or purpose of ack. The Nano 0x82 gives a company/signature. With other bytes, diverse answers are obtained. To see the following examples: 2. Example: Instruction to the card: C1 38 00 00 1A 38 16 03 2A 00 00 2B 00 00 86 11 22 33 44 55 66 77 88 82 22 41 2A 6A E7 20 75 32 90 00 Instruction to the card: C1 36 20 00 1D Answer of the card: 36 13 86 11 22 33 44 55 66 77 88 03 82 F5 CF C1 37 61 AA 07 B0 FF FF FF FF FF FF FF FF FF 90 00 P2 of the INS 0x36 in 8x probably is a chain of superencryption answer. 3. Example: Instruction to the card: C1 38 00 00 1A 38 16 00 2A 00 00 2B 00 00 86 00 00 00 00 00 00 00 00 82 EB 68 9D 67 22 23 9E 8E 90 00 Instruction to the card: C1 36 20 80 1D Answer of the card: 36 1C 7D DB 79 33 54 8D 66 2E FF 2E 54 ED 6D D2 53 31 31 B6 45 6D 73 82 FB 66 00 C2 27 B1 90 00 The significant byte of the answer in example 1 is 0x1C and in 2 example 0x13. The byte of blockade in example 1 is 0x04 and in the 2 he is 0x03 02, 05, 08, 0A, 0E, 11, 1F, 21, 22, 29, 2B, 2E, 33, 35, 47, 4E, 4F, 64, 69, 6A, 70, 7A, 90, 95, 9F, A1, A9, B0, B5, BA, BD, CC, CE, D6,DD, E7, EC, F2, F4, F8, FE. INS 0x38 Menu Ins 38: data request and PPV event recording request C1 38 xx yy 1A 16 (d1) 2A (d2 d3) 2B (d4 d5) 86 (8 bytes) 82 (signature) Superencryption may be active on exit: 29h=d1 2Dh=d2 2Eh=d3 2Fh=d4 30h=d5 87-8Eh=(8 bytes for security) d1 d2 d3 as in ins 34 d4-d5: PPV event spot The exact sense of this instruction is not known although it is related to the PPV. C1 38 P1 P2 LE 16 ww 2A xx xx 2B yy yy 86 zz zz zz zz zz zz zz zz 82 SIG P1 initialises m10F. Following the Nanos must be applied to the INS 0x38() 0x16 initialises M110 0x2A initialises m10A + m10B 0x2B initialises m108 + m109 0x86 transfers 8 bytes of data 0x82 next goes the company/signature INS 0x3A Menu Ins 3A: send to output decrypted word To this instruction the flame after one 0x3C when this ended the bytes of state 90 00. The card transmits to deco the words of control (CW). With them, deco can to decode flow MPEG-2 (the CW in flat text transfer in the registry xy of the Simple Algorithm of present Encryption in the hardware). In 0x3C we have seen that deco transmits to the card the codified W.S. These are in the card and given back to deco with 0xA. The length of the answer chain is of 16bytes. Every 10 seconds it contains two new CW of 8 bytes in clear text. Most of the conditional A(ACCESO) they change only one of the W.S. P1 and P2 is always 00. Example: Instruction to the card: C1 3A 00 00 10 Response from card: 3A 01 44 45 50 41 05 44 D4 50 10 50 D6 00 01 51 B2 90 00 1. CW in flat text: 01 44 45 50 41 05 44 D4 2. CW in flat text: 50 10 50 D6 00 01 51 B2 INS 0x3C Menu Ins 3C: ECM nano 04: give dw for output Nanocommand 04: give dw for output after nano 04 only nano D1 is valid nano 12: parental control protection Nanocommand 12: parental control protection look for pin protection status (8062h=0/1) if 20.6 = 1 then override protection nano 13: verify channel id with provider bitmap package Nanocommand 13: verify channel id with provider bitmap package 13 xx: channel id (must be <= 3Fh otherwise no decryption) channel id must be set in provider bitmap package for channel vision nano 15: PPV special management Nanocommand 15: PPV special management 15 xx: cost verify authorisation and credits, update credits and event record (or create) bit 20.3 allow special management nano 19: PPV preview control Nanocommand 19: PPV preview control 19 xx: counter initialise and update preview record and preview ppv channel nano 27: delete old PPV preview records Nanocommand 27: delete old provider PPV preview records 27 xx xx: current date verify expiration date and continue if valid nano 2C: PPV tokens management nano 2D: delete old PPV event records Nanocommand 2D: delete old provider PPV event records 2D xx xx: current date nano 31: verify PPV event id, diffusion number and vision number Nanocommand 31: verify PPV event id, diffusion number and vision number 31 xx xx xx: PPV event id (2 bytes) and diffusion number nano 82: signature nano D1: control word to decrypt Nanocommand D1: control word to decrypt if this nano is directly processed then there is an error nano F1: bitmap regional code Nanocommand F1: bitmap regional code F1 (20h bytes bitmap) regional bitmap bit 7-3 define byte (0-1Fh), bit 2-0 define bit C1 3C P1 P2 LEN The instruction 0x3C contains in its part of data the codified keys of control for a channel. This belongs to category electronic counter measures (Entitlement Message Control). The length of the chain of commandos is variable and depends among other things of the active channels (or several Channel ID’s or Channel Bundle ID’s). In the same way, this length also is influenced by additional nanos (like 0x04, to see: Nano 0x04). The Channel ID defines a unique channel, although they are possible to be grouped in a package of programs, to which also it defines. Said YOU GO occupies 1 byte. It is necessary to emphasise the fifth bit of P1 as well as the eighth bit of P2, always read of right to left. To see: Use of the keys, Instruction 0x40 superencryption. These always have to be, of course, always valid (correct index of key, index of correct provider so that the card is considered activates). Also it is necessary that the codified CW single are processed from the card, speak of codified form and they are given back with 0xÁ if the chain that contains, for example, the company/signature and the Channel YOU GO is absolutely correct. The decoding of the CW is made with the operation keys. The codification of the CW is made of direct form after the control of the company/signature. This allows the creation of sample instalments. If the instruction 0x3C contains the Nano 0x04, the process with no need aborts and the decodification program of an instalment. The Nano 0x04 belongs therefore to the Channel Bundle ID (also called information of bouquet.) and to the date (to also see date format). It is important to say that after from CAM sent of this instruction activates the option to card. In our program, so that deco I sent to the card the data to de encrypt them. Three main types of instructions exist 0x3C: for a standard channel, for a channel PPV with preview and a channel PPV without preview. The following nanos can be used with 0x3C: 0x04 can free be made the subscription of the subscriber to the channels (for example, for tests) without asking if channel ID is part of the Abo. 0x12 the parental control is transmitted in the data flow. The PIN of parental control is requested if he is active. 0x13 follows the Channel Bundle ID to him 0x15 Process of PPV, probably allows vision of bought events ppv with cards. 0x19 Process PPV with preview, the successive data activates an accountant who decrement in 1 with each 0x3C, therefore, every 10 seconds, and when reaching zero stops the decoding of the CW. Combination with the preceding nano 0x31 a registry AX, if it is a transmission with preview, in which writes the accountant and when any registry of provider PPV (BX) with the same PPV-EventID does not exist. If a registry of provider PPV (BX) for this transmission exists, then 0x27- is placed to him the date of the nano Three events PPV of the same day are written in the same registry even though the accountant reaches zero; with more than three events a new registry is created. For the erasure of registries, to know more on the registries of the nanos 0x27 and 0x31, to see the nano 0x27. Example of a registry of preview of PPV provider: 32 D2 00 1A 17 FE 08 08 00 09 08 04 00 00 00 A2 00 00 03 90 00 Date: 17 FE PPV-EventID: 08 08 / Accountant to 00 PPV-EventID: 09 08 / Accountant to 04 0x2C Process of PPV, perhaps when it is bought by cards; a byte to represent or the cost or the accountant of a possible purchase 0x2D Process of PPV. 0x27 follows the date of the transmission, to see: format of dates Flock all the registries of preview with later date to the one of the specified provider (a INS 0x3C only with a Nano 0x27 flock registries AX of the card if it finds dates more recent, without creating other new ones) Note: If are two registries AX in the card and the INS 0x3C contains more recent dates for the same PPV-EventID, these will erase only with one second 0x3C The dates 0x3C by means of the combination of the Nano0x31 and 0x19 are written in the Ax registry in a later process of the INS 0x31 Process PPV, gives to the PPV-EventID (both first bytes) as well as the serial number of the transmission (these three bytes altogether represent a transmission PPV) An increase of the number of present transmission by means of the shipment of 0x3C to the card decrement the number of the registry of provider PPV (BX Record), that defines whichever times can be seen a transmission PPV. The number of present transmission goes in the registry of provider PPV. If one is a transmission with preview and if any registry of provider PPV (BX) with the same PPV-EventID does not exist, will be created a registry AX with the following nano 0x19. If a registry of provider PPV for this then transmission exists it introduces the date of the nano 0x27 to him. 0x71 will be ignored by 0x3C; the data for this parameter are for many providers just like for a channel of PPV 00 0x82 follows the company/signature 0x87 ignored by 0x3C 0xD1 follows the CW codified 0xF1 follows bitmap and the regional code The card basically will ignore the unknown nanos. The instructions that follow the unknown nano will be ignored until the length of the nano. Examples of chain formats: 1 Byte Nano 0x71 (71) 1 Byte (00) 2 Bytes Provider ID (00 14) 2 Bytes present year in hex (07 CE = 0x7CE = 1998) 2 Bytes present month in hex (00 07 = 0x7 = July) 1 Byte Nano 0x27 (27) 2 Bytes Date of the transmission (10 F5 = 31.07.1998) 1 Byte Nano 0x13 (13) 1 Channel Bundle ID Byte; since a channel can belong to several Channel Bundle we are the right of the variable length here (01) 1 Nano Byte 0xD1; they follow the CW codified (D1) 8 Byte codified Control Word 1 (96 88 7A 31 É 7D BD 19) 8 Codified Control Word byte 2 (9D A0 79 EE F1 E7 A0 80) 1 Byte Nano 0x82; it follows the key (82) 8 Bytes Company/signature (76 2E 2A 53 FC A9 08 B4) Example: [Codifies cw of provider 1, will use primary key 0D, 0D] Instruction to the card: C1 3C 01 0D 27 Data (like always, the instruction in the greatest field): 71 00 00 14 07 CE 00 02 27 10 F5 13 01 D1 96 88 7A 31 3E 7D BD 19 9D A0 79 EE F1 E7 A0 80 82 76 2E 2A 53 FC A9 08 B4 Echo of the card: 3C 71 00 00 14 07 CE 00 02 27 10 F5 13 01 D1 96 88 7A 31 3E 7D BD 19 9D A0 79 EE F1 E7 A0 80 82 76 2E 2A 53 FC A9 08 B4 90 00 It transmits single in the instruction. INS 0x40 Menu nano 01: set nano 24 flag to FF nano 02: set nano 24 flag to 00 Store date and new credits in ppv credits record (ins 40 nano 42) r6-r7: credits number r4-r5: date on exit: c set if all ok Ins 40: EMM key must be 0-b, in ATR level 2 bit7 of key index must be clear if 20.2 is set then activate eeprom indication status code 90 90 = eeprom not updated status code 90 A0 = eeprom updated (modified or deleted) Update date and credits in ppv credits record (ins 40 nano 43) r6-r7: credits number r4-r5: date on exit: c set if all ok Write special credits in ppv credits record (ins 40 nano 30) r7: credits number r4-r5: date on exit: c set if all ok Nanocommand 02: set nano 24 flag to 00 02: no data nano 03: delete pin code nano 10: delete given key (primary and secondary) nano 11: delete seca record of a given type Nanocommand 11: delete SECA record 11 xx: type nano 17: write regional bitmap Nanocommand 17: write regional bitmap 17 xx: regional bitmap nano 18: delete service preview record Nanocommand 18: delete service preview record for SECA only 18 xx: ident of service preview record nano 1D: set 8022 eeprom location Nanocommand 1D: set [8022] eeprom location for SECA only [8022] location must be 00h or 55h 1D xx: if xx=00 then [8022]=55h ; if xx=55h then [8022]=FFh nano 1E: set 8020 eeprom location Nanocommand 1E: set [8020] eeprom location for SECA only [8020] must be 00h or 55h 1E xx: if xx=00 then [8020]=55h ; if xx=55h then [8020]=FFh nano 1F: set 8021 eeprom location Nanocommand 1F: set [8021] eeprom location for SECA only [8021] location must be 00h or 55h 1F xx: if xx=00 then [8021]=55h ; if xx=55h then [8021]=FFh nano 21: set expiration date Nanocommand 21: set expiration date 21 xx xx: date nano 22: verify expiration date Nanocommand 22: verify expiration date 22 xx xx: date nano 23: add new provider nano 24: apply next nanos to given provider nano 25: delete given provider nano 26: modify provider space for records and flags nano 28: delete a ppv preview record Nanocommand 28: delete a ppv preview record 28 xx xx: date nano 30: store special credits in ppv credits record Nanocommand 30: store special credits in ppv credits record 30 xx xx yy: date and credit nano 32: seek or create record for a given event-id nano 33: create or modify service preview record Nanocommand 33: create or modify service preview record for SECA only 33 xx xx xx: ident and counter nano 40: delete ppv event record with event-id between min-max Nanocommand 40: delete ppv event records with event-id between min-max 40 xx xx yy yy: minimum and maximum nano 41: set PPUA Nanocommand 41: set PPUA 41 xx xx xx xx: PPUA nano 42: store data and new credits in ppv credits record Nanocommand 42: store data and new credits in ppv credits record 42 xx xx yy yy: date and credits if credits = 0 then delete record nano 43: update data and add credits in ppv credits record Nanocommand 43: update data and add credits in ppv credits record 43 xx xx yy yy: date and credits nano 80: set provider bitmap package Nanocommand 80: set provider bitmap package 80 (8 bytes data): bitmap package nano 82: signature nano 87: set provider data for ins 44 Nanocommand 87: set provider data for ins 44 (stored in 2b-2ch) 87 (8 data bytes): ins 06 word previous ins must be 06, data must be the same of ins 06 nano 90: write primary key Nanocommand 90: write primary key 90 (9 bytes data): index and key nano 91: write secondary key Nanocommand 91: write secondary key 91 (9 bytes data): index and key nano B0: store SECA record of a given type Nanocommand B0: store SECA record B0 xx (10 data bytes): type and data nano D0: change provider name Nanocommand D0: change provider name D0 (16 data bytes): new provider name nano F0: verify CustWP Nanocommand F0: verify CustWP F0 (20h bytes data): customer word pointer bitmap INS 0x40 C1 40 P1 P2 LEN The instalments administer through the instruction 0x40. By means of her, the provider can manage the aim of an instalment, extension of the same one, purchase of events PPV, card purchase, update of keys, etc... All it belongs to the category of EMM (Entitlement Management Message). The address can be made on a card (on UA/Serie), to all cards or card a specific assembly of a group. For the last possibility, it is necessary to provide the shared direction (shared address) as well as byte CustWP. The fans to the IRDETO will remember the B20-CMatrix: Bitmap of CustWP of a maximum of 256Bits forms (32 bytes). If the first byte is active then direction the first letter of Group indicated by the SA. The following nanos can be used with 0x40, although precaution in as much is recommended does not know the complete use of some. a) Single useful for provider 00 (DRY) 0x18 + 1 Byte of data flock a registry AX (created with the INS 0x40 Nano 0x33 and the INS 0x3C); given the first byte of registry AX; to see: Nano 0x33 0x1D +1 Byte of data writes the given byte in the EEPROM, position E01A. Flag of protection can take value 00, 55 or FF. If E01A is 00, a value from 00 to 55, or with a value different from 00 can be put from FF. If E01A is 55, a value different from 00 can be given FF, 00 does not have no effect. If E01A is FF, the value cannot return to modify itself. The optimal value is 55, since with him the protection is deactivated 0x1E + 1 Byte of data writes this byte in the position E018 of the EEPROM. Flag of protection protects the instructions 0x50 and 0x54. Ver the values in the Nano 0x1D. 0x1F + 1 Byte of data writes this byte in the position E019 of the EEPROM. Flag of protection protects the instruction 0x56. Ver the values in the Nano 0x1D. 0x23 + 2 Bytes of data both Adds the provider specified by bytes 0x24 + 2 Bytes of data checks if the provider specified by both bytes is available and checks if the following nanos are of application with this provider. 0x25 + 2 Bytes of data both Eliminates the provider specified by bytes 0x26 + 2 Bytes of Permite/deshabilita data the creation of new registries for the provider specified by both bytes Example: 26 FF FF FF FF = 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 = 16 Bit ^----- a (1-10)-----^ ^ b (11) ^ c (12) ^-^ d (13-14) ^ e (15) a) Value máx. of the bytes of registry for that provider b) Must be activated with the Nano 0x32 c) Must be activated with the Nano 0x80 d) Must be activated with the Nanos 0x30, 0x42, 0x43 e) 0x01 must be activated with the Nano 0x33 + 3 Bytes of data à creates a registry AX, if he is not available contains an accountant. The registry can be directional from the first byte Registry AX can erase with the nano 0x18; the accountant decrement by means of the nano 0xD1 of the protected instruction 0x44 The use of a registry AX as registry of preview PPV is made by means of the INS 0x3C with data for the phase of preview, reason why this one registry AX has to have another use. If the registry were created with the Nano 0x33, the erasure can be made with the INS 0x3C, if the third byte has value 00 If 0x3C can modify a registry AX with the INS, the second byte of the date as well as the first byte of the PPV-EventID b) Rest 0x01 Describe 0xFF in the structure of provider with Offset 0x1B; No longer 0x24 can be directional more to the provider by means of the Nano 0x02 writes 0x00 in the structure of provider with Offset 0x1B; We can continue directional the provider through the Nano 0x24 0x03 pon the PIN to null. 0x10 + 1 Byte of data flock the key indicated by the byte of the provider. 0x11 + 1 Byte of data Flock a DRY registry of the type specified by the byte 0x17 + 1 Byte of data Writes the byte in the structure of provider with offset 0x18; Regional code. 0x21 + 2 Bytes of data Active the date of instalment aim 0x22 + 2 Bytes of data Checks the date of instalment aim 0x28 + 2 Bytes of data Flock registry AX 0x30 + 3 Bytes of data Process of PPV; probably it activates some type. 0x32 + 3 Bytes of data Process of PPV; it is sent to the card after the request and buys of an event PPV (2 Bytes of PPV-EventID + 1 Byte of accountant, that whichever times indicate can be seen an event PPV in the concrete day) à creates a registry BX (Provider PPV Record), with the date to FF FF. 0x40 + 4 Bytes of data flock registries PPV of the area of data included/understood by the four bytes (aabb until ccdd) 0x41 + 4 Bytes Date writes the PPUA 0x42 + 4 Bytes Date a) Writes the bought cards in the card (2 Bytes of date + 2 Bytes of I number of cards, to see: Registries of credit of provider PPV, à modifies the number of cards) creates a registry DX (registry of credit of provider PPV) b) 42 00 FF FF 00 flock the registry of credit of provider PPV 0x43 + 4 Bytes Date modifies the cards bought in card (2 Byte of date + 2 Bytes nro. of cards, to see: registry of credit of provider PPV, modification of the number of cards) 0x80 + 8 Bytes of data next goes the package of bitmap for the provider; with [ 8*FF ] we obtain access to all the programming 0x82 + 8 Bytes of data follows the company/signature 0x87 + 8 Bytes of data releases to the protected instruction 0x44, the 8 bytes of data must be identical with mF0E (INS 0x06); 0x44 initialises the buffer of encryptación for the following INS 0x90 + 9 Bytes of data if it follows the index of key as well as the encrypted primary key 0x91 + 9 Bytes of data follows the index of key as well as the encrypted secondary key 0xB0 + 11 bytes of data writes a DRY registry of the type that specifies in the data (ej: activation registry) 0xD0 + 16 bytes of data follows the Provider ID chain 0xF0 + 32 bytes of data follows the UCScTcWcP-cBitmap It is important to know that to send this instruction CAM is necessary to activate the option to Card. of our program, since the data are had to send to the card. The length of the chain of commandos is variable. Example: [We will use primary key 02 and (if it is stored) secondary key 02 for provider 08, to see: Use of the keys; when an instalment is requested, superencryption is used, initialises a buffer of hash with [ 8*00 ]; Explanation: to see more down] Instruction to the card: C1 40 19 82 35 Data: 96 E8 5D 3B 97 26 6E B1 82 0F 87 17 D3 5C 87 47 34 5E 39 79 2F 8E 84 4C 16 E2 3A 6A A3 40 30 C9 05 5F BB 01 56 11 7C 4F BF 1F C3 32 21 BD 13 D9 60 53 25 CB 9E First then the instruction is sent. Echo of the card: 40 96 E8 5D 3B 97 26 6E B1 82 0F 87 17 D3 5C 87 47 34 5E 39 79 2F 8E 84 4C 16 E2 3A 6A A3 40 30 C9 05 5F BB 01 56 11 7C 4F BF 1F C3 32 21 BD 13 D9 60 53 25 CB 9E 90 00 We do not have any significant example! The base is in the mentioned procedure of superencryption, that according to seems to be do not control all cards. In the chain that is sent to the card codified data go (for example, operation keys) that become to codify by means of the use of the keys specified in P2 for the provider specified in P1, before they are transmitted, beginning by the first byte and even some bytes of the company/signature. This procedure also is possible for 0x3C although at the present time it is not used. Single the cards from version 4,0 control the superencryption of the ECMs! P1 contains the provider (in the example of above the 09) and also regulates the use of the keys primary and secondary (to see: use of the keys, fifth bit). P2 gives the index of key (in example, key 02), as well as the control of the use or not of the superencryption. If the eighth bit (as always counted of right to left) of P2 is active, then we will have superencriptación. Again, we used the computer of Windows in scientific way (it is to us from much aid): We happened, for example, the number hex 82 to binary and obtain: 10000010. We see that the eighth bit is active (1 instead of zero): superencriptación will be used. P1 says to us as the buffer will be initialised hash for I calculate of of the company/signature. It will be necessary to resort to the documentation of the algorithm to know how one treats and how it works. The structure from bits of P1 is to us useful, mainly the three superior bits: a) 001x xxxx Initialise hash with: 6 Bytes UA (Card Serial) + [ 2*00 ] b) 010x xxxx Initialise hash with: 4 Bytes PPUA + [ 4*00 ] c) 011x xxxx Initialise hash with: 3 Bytes SA + [ 5*00 ] d) rest Initialise hash with: [ 8*00 ] It seems strange to say that the highest bit does not serve to us. At the moment the provider only uses the boot with [ 8*00 ]. In relation to the content defined in bits of P1 (Provider 0-F; Key Primary / Secondary. Regulation and boot of the buffer hash) we have the following objectives: a) 0x20. 0x2F (by PK, PK). 0x3F (by PK, SK) b) b) 0x40. 0x4F(by PK, PK). 0x5F (by PK, SK) c) c) 0x60. 0x6F(by PK, PK). 0x7F (by PK, SK) d) d) 0x00. 0x0F(by PK, PK). 0x1F (by PK, SK) The data go to the card from the CAM. The single card verifies that hash is correct and if is therefore the message is processed. Other types of EMM.s: a) For all the subscribers = EMM-G (General.) b) To all cards of a group determined, specified with SA + UCScTcWcP-cBitmap) = EMM-S (Group shared of clients.) c) A particular subscriber, by means of UA / Card Serial = EMM-U (Unico.) The technique of the superencriptación goes destined to make the reading more difficult of the data. The card encrypt each block of 8 bytes with the algorithm. We obtain then blocks of 8 codified bytes. If they are less than 8 bytes, then the rest is not codified. There is enough EMM.s possible, these Varian in interval of shipment and change of the code and the language. INS 0x42 Menu Ins 42 and ins 8A: output results of ins 44/58/8C Output results for ins 42 and 8A r7: offset for superencryption Ins 42 and ins 8A: output results of ins 44/58/8C for ins 42 the superencryption (optional) is over all bytes for ins 8A the superencryption (optional) is over all bytes skipped first 8 INS 0x44 Menu Ins 44: service ECM/EMM computation Encrypt given words (ins 44 nano D1) Nanocommand D1: verify service preview record and encrypt given words D1 (16 bytes data): words to encrypt nano 71 must be before nano D1 Nanocommand 71: create hash buffer 71 (7 data bytes): data not significant P1-P2 hash buffer is copied in the nano 7-bytes space nano 71 must be before nano D1 nano 23 and 24: apply next nanos to given provider Nanocommand 23 and 24: apply next nanos to given provider 23/24 xx xx: provider ident nano 25: apply next nanos to current provider Nanocommand 25: apply next nanos to current provider (P1) 25 00 00: no data nano 71: create hash buffer nano 82: create signature Nanocommand 82: create signature 82 (8 bytes data): data not significant signature is copied in the nano 8-bytes space nano 87: encrypt given word (without controls) Nanocommand 87: encrypt given word (without controls) 87 (8 bytes data): word to encrypt nano 90 and 91: create key derived from given hash buffer and index Nanocommand 90 and 91: create key derived from given hash buffer and index 90/91 (index)(hash) P2 key must be 0-B, index bit 5 must be clear Initialise hash buffer, encrypt with with P2 keys, encrypt with ins 44 keys results are copied in the 9-bytes nano space nano D1: verify service preview record and encrypt given words INS 0x48 Menu Ins 48: set flags 20.2 and 20.5 C1 48 00 00 01 (data byte, bit 4 and 5) C1 48 00 00 01 xx This instruction activates bits 4 and 5 of m080 (to see tb. The INS 0x30. m80), P1 and P2 are 00. Value xx originate the following changes in the registry m080. xx =0x00 m080,4 = 0; m080,5 = 0 xx =0x10 m080,4 = 1; m080,5 = 0 xx =0x20 m080,4 = 0; m080,5 = 1 xx =0x30 m080,4 = 1; m080,5 = 1 The INS 0x16 shows among other things this registry. This instruction 0x48 is not supported in all the types of card. The Num30 does not recognise it, for example. Ins 4A: show [8028-8047] and [8020-8021] contents INS 0x4A Back to Top Ins 4A: show [8028-8047] and [8020-8021] contents C1 4A 00 00 22 C1 4A 00 00 59 This instruction gives back bitmap of the Nanos allowed for the INS 0x44, as well as the values of E018 and E019 (in 34 bytes 33 and decimal) and 2 bytes 00 00 for Num 60, whose meaning is not known. Normally these values go to FF. Assumes the length of 0x59 to use the totality of the exit buffer here. Also we found here other bytes in newer versions of BIOS. P1=00, P2=00. INS 0x4C Menu Ins 4C: set array [8028-8047] and [8020-8021] ins with ATR 2 and flag protection len must be 22h data for [8028-8047] will be or-ed with eeprom contents and stored there if data for [8020-8021] <> 00 then store FF in these locations C1 4C 00 00 22 DATA This instruction writes bitmap of the allowed nanos (alternative procedures EMM). Single he is available in way under programming. It is had to activate the bit of test 7 of m080. Example: Instruction to the card: C1 4C 00 00 22 4C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 97 01 The area from E020 will be OR-eada with the data and soon written. Xx OR FF gives FF, the data in this one single area can be increased, not to decrement itself. This process is irreversible. Byte 32 puts flag of protection E018 to FF, when the given value is not 00 and E018 does not have value FF. If it occurs 00, does not take place any writing in E018. When byte 33 is 00, or when E019 has value FF, any writing in E019 does not take place. INS 0x50 Menu Ins 50: add new provider Ins 50: add new provider ins with ATR 2 and flag protection [8020] must be 55h C1 50 00 00 02 (provider ident) This instruction is only available in the low way of programming. The bit of test 7 of m080 is due to activate and also we will have to put 0x55 in flag of protection E018. C1 50 00 00 02 xx xx INS 0x50 can modify the provider without company/signature. P1 = 00, P2 = 00. xx xx indicate ident of the provider to write INS 0x54 Menu Ins 54: store new key to eeprom ins with ATR 2 and flag protection [8020] must be 55h C1 54 P1 P2 09 (index - key) P2 bit 4: if clear then primary key This instruction is only available in low way of programming. The bit of test 7 of m080 must be active. Also we have to have 0x55 in flag of protection E018. C1 54 P1 P2 09 xx yy yy yy yy yy yy yy yy INS 0x54 writes key in clear text in the LPM. P1 contains the provider for which we wrote a key in clear text. P2 will say if the key like primary key (bit4=0) or secondary key is written (bit4=1, example, 0x10) Xx it contains the key index, 8*yy the key in clear. INS 0x56 Menu Ins 56: encrypt given word (ins 5C) with P2 key ins with ATR 2 and flag protection [8021] must be 55h previous ins must be 5C P2 bit 4 show pri/sec key - key index bit 6 and 5 must be clear Only available in low way of programming. Assets bit 7 of m080 and 0x55 in flag of protection E019. Before we have to send one 0x5C. C1 56 P1 P2 08 P1 contains the provider, P2 contains the key. Bits 5.6 of the index of keys will not go active. The INS 0x56 encrypt the 8 bytes given with the INS 0x5C (key virtual) with the key at the moment in the card and between the result. This instruction also checks the key. INS 0x58 Menu Ins 58 and ins 8C: verify signature for a given sequence ins with ATR 2 protection P1 bits 7,6,5 and P2 bits 6,5,4: bytes for hash initialisation superencryption may be active (P2 bit 7) 58 -> superencryption with all bytes (future 40 ins) 8C -> superencryption without first 8 bytes (future 3C ins) The function of this instruction is not known in the present time. INS 0x5A Menu Ins 5A: encrypt null word if P2 bit4 is clear then encrypt null word with P1-P2 keys (yes!) if P2 bit4 is set then we must be in ATR level 2 and previous ins 5C then initialise hash buffer with 5C word, encrypt with P1-P2 keys these are new keys to encrypt null word This instruction uses the key specified with P2 (index) and P1 (entered: PK/Pk+SK) to encrypt the text in clear (text none encryption) 00 00 00 00 00 00 00 00 and to give it like based text (encrypted text). The intention of this instruction still is not known unfortunately. Since for this calculation a buffer is needed hash (it means that a value will be modified time and time again and the final value does not have sense), we did not count on a value of return. C1 5A P1 P2 08 P1 gives the provider (00 are DRY) as well as single if they will be used the primary key or the primary key and the secondary one (in this case 1X, fourth active bit), P2 takes the key index. Example 1: [Is used the primary key 0x00, key primary 0x00 for provider 00 DROUGHT ] Instruction to the card: C1 5A 00 00 08 Answer of the target: 5A D2 E9 44 1B E3 B1 AE 0B 90 00 00 00 00 00 00 00 00 00 encryption therefore with primary key 00 + primary key 00 of DROUGHT. The result is D2 E9 44 1B E3 B1 AE 0B. Example 2: [Is used the primary key 0x00 plus the secondary key 0x00 for provider 00 DROUGHT, if the primary key is stored and goes like 0x10, if the primary key is not used 0x00 + primary key 0x00 ] Instruction to the card: C1 5A 10 00 08 Answer of the card: 5A 89 BC 01 96 F4 02 B4 2E 90 00 00 00 00 00 00 00 00 00 encryption with primary key secondary + of DROUGHT. The result is 89 BC 01 96 F4 02 B4 2E. If there is no key available with the given parameter, we obtain 5A [8*FF] 90 04. Other characteristics: If the card is in low way of programming, the INS 0x5A can also use a temporary key stored with the preceding INS 0x5C (instead of 8*00). For it, it is necessary that P2 = 1X (fourth active bit). If in this case the fourth bit of P1 is not active (0X), TPK + TPK will be used (key weather + temporary key). If he is active (1X), will be used TPK + TSK (key primary weather + secondary temporary key). Ver INS 0x5C INS 0x5C Menu Ins 5C: give 8 bytes data for ins 56/5A C1 5C xx yy 08 (data) C1 5C P1 P2 08 xx xx xx xx xx xx xx xx This instruction writes a temporary key in the memory, which can be used for example with the INS 0x5A or 0x56 in way under programming. xx = Key weather of the 8 bytes P1 contains the provider, P2 contains the key, with which they are going away to encryption the 8 given bytes. The result contains the temporary key. Example: Key primary 0x00 of provider 00 of the card is: 00 00 00 00 00 00 00 00 Key secondary 0x00 of provider 00 of the card is: 11 11 11 11 11 11 11 11 Instruction to the card: C1 5C 00 00 08 5C 11 22 33 44 55 66 77 88 90 00 The single card encrypt 11 22 33 44 55 66 77 88 with PK + PK and writes the primary key temporary B5 63 69 3c 13 96 DC 8C in the area of designated memory. In addition, the card encrypt 11 22 33 44 55 66 77 88 with SK + SK (again the secondary key, noncPk + SK) and 11 DD C3 write the temporary secondary key 50 29 99 9A 1C in the area of designated memory INS 0x7C Menu Ins 7C: Change I/O mode and set timing (for eeprom write) must be: len = 3 if d1 <> ff then set only timing if d1 = ff and ATR = level 2 then set timing and I/O mode flag d2 and d3 define time delay must be: 3<d2<32 and e8<d3<c8 With this instruction the way of OCMs of the card can be modified, especially of parity and delays. I do not know why it serves this. C1 7C 00 00 03 xx yy yy If xx have value FF and the card is not in way under programming, bit 7 of m081 activates, in another case, bit 7 of m081 does not activate. If m080,7 = 0 ist, selects the COM to 9600 bauds, 8 bits of data, even parity and 1 but of shutdown. If m0870,7 = 1, selects the COM to 9600 bauds, 8 bits of data, without parity, a stop bit. The standard value of m080 is 0x7F = 1111111 = Bits6, 5, 4, 3, 2, 1, 0 assets; None active Bit7. This it is the way of standard work of the card in the COM in which the LPM is not used, 9600-8-NONE-1. Yy yy will go located in the area between $03e8 - $32c8. If this it is the case, the value of delay for the card will be modified: yy yy / 64 = m106 = new delay. In opposite case we obtain the message of error 98 01 (except in the Num60). After reset, m106 will return to the value 0xÉ (decimal 62), that corresponds to 0x0F80. The value of delay (delay) can take ranks between 15 and 203. P1 = 00, P2 = 00. RAM DIRECT-INDIRECT ACCESS MAP Menu 00-01 r0-r7 08 total byte received counter 09 data buffer byte counter (bytes to output) 0A-0B record offset (must be added to 8070h) 0C-0D record number (max 127h) 0E-0F indicators for record seeking 10-1B record buffer 1C-1D record address (eeprom) 1E counter for ins 44 20.0 0 ppv management (ins 3C nano 15) set byt ins 30 20.1 1 not used, set by ins 30 20.2 2 eeprom update indication (if set then indicate eeprom update in ins 40) set by ins 48 20.3 3 ppv management, allow special management (ins 3C nano 15) set by ins 30 20.4 4 I/O mode flag (set synchronous, clear asynchronous) set by ins 7C 20.5 5 ppv management (clear=all event transactions allowed) set by ins 48 (ins 3C nano 31) 20.6 6 override parental control protection flag (if set then override) set by ins 30 20.7 7 ppv management (set=single event transaction allowed) set by ins 30 (ins 3C nano 31) 21.0 8 instruction protected flag (ins 4C,50,54,56) (if set then ins unlocked) set by ins 30 21.1 9 eeprom written flag (1 eeprom modified, 0 eeprom not modified) 21.2 A ins 32/36 more output flag, ins 3C nano 15 flag, ins 40 nano 90-91 flag ins 40 nano 10 flag Nanocommand 10: delete given key (primary and secondary) 10 xx: key index 21.3 B verify signature flag (1 verify signature, 0 ignore signature) key flag (0 primary key, 1 secondary key) superencryption flag (1 encrypt, 0 decrypt) 26-27 offset of first free provider area (must be added to 8070h) 28 current provider number (00-0Fh) 29 ins 32/34/36/38 data 2A ins 36/38 provider 2B-2C provider data for ins 44 2D-2E ins 32/34/36/38 data 2F-30 ins 36/38 data 31-40 bottom key buffer 41 nano counter 42-43 starting address of current provider area 44 algo constant 47 previous ins 48-49 status bytes 4A-51 hash buffer 52-56 dynamic array 63-6A provider pbm (ins 3C) 71-80 top key buffer 81 command 82 ins (cam-to-card bit 1 clear, card-to-cam bit 1 set) 83 P1 84 P2 85 length 86-E4 data buffer E5-FF stack pile PROVIDER 1 (28 bytes) 8070 ident provider 1 (2 bytes) 8072 nano flags and max space (2 bytes) Nanocommand 01: set nano 24 flag to FFh 01: no data bit 0F ins 40 nano 01 flag bit 0E ins 3C nano 15 flag (ppv special management) bit 0D ins 3C nano 2C flag (ppv tokens management) bit 0C ins 40 nano 80 flag (provider bitmap package) bit 0B ins 40 nano 32 flag bit 0A-00 maximum number of bytes for records 8074 provider name in ascii code (16 bytes) 8084 ppua (4 bytes), (SA = first 3 bytes, CUSTWP = last byte) 8088 expiration date (2 bytes) 808A nano 24 flag (1 byte), (00=enabled FF=disabled) 808B regional code (1 byte) RECORD TYPES Menu SECA RECORD 00 type 01-0A data 0B E0 PPV CREDITS RECORD 00-01 total credits 02 total special credits 03-04 last credits 05-06 date last update 07 special credits authorisation 0B Dx (x=provider) SECONDARY KEY RECORD 00 key index 01-08 key 09 checksum 0A 00 0B Cx (x=provider) PPV EVENT RECORD 00 type (0=unused/1=normal use/2=special use) 01-02 event id 03 diffusion number 04 number of visions 05-06 event cost 07-08 date 09-0A user spot 0B Bx (x=provider) PPV PREVIEW RECORD 00-01 date 02-04 event id and counter 05-07 event id and counter 08-0A event id and counter 0B Ax (x=provider) SERVICE PREVIEW RECORD 00 ident of service 01-02 counter 0B Ax (x=provider) PROVIDER PBM (bitmap package) 00-07 bitmap package 0B 9x (x=provider) PRIMARY KEY RECORD 00 key index 01-08 key 09 checksum 0A 00 0B 8x (x=provider) RECORD ADDRESS FORMULA 8070+(0F7C-RECNUM*C) with (0F7C-RECNUM*C)<8000h Seek a record Menu 0fh: if 00 then seek a free record 0eh: if ff then seek a record of given provider if 00 then seek a primary key of given provider if 10 then seek a pbm of given provider if 20 then seek a preview record of given provider if 30 then seek a ppv event record of given provider if 40 then seek a secondary key of given provider if 50 then seek a ppv credits record of given provider if 60 then seek a SECA record on exit: carry set if record found (record is "pointed") SECA INS LIST Menu Ins 02: output encrypted data with ins 04 Ins 04: encrypt data with key F Ins 06: output a random word Ins 0A: output micro type, rom checksum and card version Ins 0C: initialisation commands P2 = 0 change serial number P2 = 1 init SECA P2 = 3 change mode (from level 3 to level 1) P2 = 4 change mode (from level 3 to level 2) and delete [8020-22][80288047] Ins 0E: output serial number of the card Ins 12: output provider id-string and regional bitmap Ins 16: output providers bitmap, pin prot status and flags Ins 1A: output primary keys index for given provider Ins 30: pin transactions P2 = 0 insert/modify pin P2 = 1 modify pin protection status P2 = 2 modify flags (6 bits) Ins 32: output data requested with ins 34 Ins 34: data request Ins 36: output data requested with ins 38 and PPV event recording Ins 38: data request and PPV event recording request Ins 3A: send to output decrypted word Ins 3C: ECM nano 04: give dw for output nano 12: parental control protection nano 13: verify channel id with provider bitmap package nano 15: PPV special management nano 19: PPV preview control nano 27: delete old PPV preview records nano 2C: PPV tokens management Nanocommand 2C: PPV tokens management 2C xx xx: event cost and vision number verify credits, update PPV credits record, create PPV event record nano 2D: delete old PPV event records nano 31: verify PPV event id, diffusion number and vision number nano 82: signature nano D1: control word to decrypt nano F1: bitmap regional code Ins 42 and ins 8A: output results of ins 44/58/8C Ins 44: service ECM/EMM computation nano 23 and 24: apply next nanos to given provider nano 25: apply next nanos to current provider nano 71: create hash buffer nano 82: create signature nano 87: encrypt given word (without controls) nano 90 and 91: create key derived from given hash buffer and index nano D1: verify service preview record and encrypt given words Ins 48: set flags 20.2 and 20.5 Ins 4A: show [8028-8047] and [8020-8021] contents Ins 4C: set array [8028-8047] and [8020-8021] Ins 50: add new provider Ins 54: store new key to eeprom Ins 56: encrypt given word (ins 5C) with P2 key Ins 58 and ins 8C: verify signature for a given sequence Ins 5A: encrypt null word Ins 5C: give word for ins 56/5A Ins 7C: change I/O mode and set timing (for eeprom write) Greetings Menu Special thanks and respect to in no particular order: Echelon, Bigtimothy, Gribley, Bod, Cannonball, Dpeters, Minirolls, Twojags, Ixus, Parisino, Raiden, Kinkdink, Boycie, BOB, Coalman, Courier, TOECUTTER, 28BAY, Chimby, Philbert, Iceman, Sinbad, TJ, Shoog, MrSporty, Lazer, AltheTaff, Satsid, Rooster, Artful, TJ, Duwgati , Niceeee, Iceman, Q2uantum, Deepdark, M_houllier, MajorFU, Northernbloke, CJ, Dasdl, Dunker, AJR Big thanks to the Mrs and daughter who keep me in check. |