Log in
Register
Menu
Log in
Register
Home
What's new
Latest activity
Authors
Forums
New posts
Search forums
What's new
New posts
Latest activity
Members
Current visitors
New posts
Search forums
Menu
Log in
Register
Install the app
Install
Forums
Satellite TV receivers & systems support forums
Satellite Systems - What to Buy - What to install
How is it possible to scramble channels with multiple encryptions?
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="kalamar" data-source="post: 51485"><p>The NagraVision cards use a variant of the ISO-7816 protocol called the</p><p>"T=1" or "asynchronous half-duplex block transfer" format. This format</p><p>differs from the format used by DSS smartcards in that the DSS protocol (the</p><p>"T=0" format) calls for the master device (the receiver or IRD) to send a</p><p>5-byte header block to the card. The card (or CAM) must then send back one</p><p>of the bytes from the header (specifically, the second byte, which is the INS</p><p>byte) to acknowledge receipt of the header. At this point, the IRD will</p><p>either send the rest of the message to the CAM as one large packet, send the</p><p>rest of the packet one byte at a time, awaiting an acknowledgment after each</p><p>byte, or await the data return from the CAM.</p><p>The T=1 protocol, on the other hand, is defined such that any of 7 devices</p><p>all connected to the same ISO-7816 bus may initiate a transmission to any</p><p>of the other devices on the bus. In addition, the message will either be</p><p>sent all at once (if it is short enough to fit in the destination device's</p><p>receive buffer), or broken into smaller packets if the message is too long</p><p>to be sent all at once.</p><p>The protocol used by the NagraVision smartcards (and in fact, by any</p><p>ISO-7816 compliant smart card) is requested by the card when it is reset by a</p><p>master device. After reset, the card will send a sequence of data at a fixed</p><p>baud rate (input clock frequency/372...it seems like an arbitrary number, but</p><p>if the input clock frequency is 3.579545 MHz, the baud rate is 9622 bps...and</p><p>although 3.579545 MHz seems like a strange number, it's actually pretty</p><p>common: It's the frequency used by the colorburst crystal in NTSC televisions</p><p>and set-top boxes), and this data will include information about the data</p><p>format the card wants to use, the baud rate at which it will want to</p><p>communicate, and so on. To better understand the NagraVision cards, let's</p><p>look at the ATR sent by a ROM3 Nagra card (specifically, this ATR came from an</p><p>EchoStar 288-02 card, but the same ATR has been seen from cards used for</p><p>ExpressVu, SkyVista, and Via Digital):</p><p></p><p>3F FF 95 00 FF 91 81 71 64 47 00 44 4E 41 53 50</p><p>30 30 33 20 52 65 76 3x 3x 3x nn</p><p></p><p>If we break this ATR up into its constituent parts, we can decode it as</p><p>follows:</p><p></p><p>3F ... Convention definition</p><p>|</p><p>|_____________ Inverse convention (data is inverted)</p><p></p><p>FF 95 00 FF 91 ... Initial parm setup</p><p>| | | | |</p><p>| | | | |_ Td1=91 (Ta2 and Td2 will be sent, Protocol is async</p><p>| | | | half duplex block format)</p><p>| | | |____ Tc1=FF (Guard time=257 bits)</p><p>| | |_______ Tb1=00 (No Vpp)</p><p>| |__________ Ta1=95 (F=512, D=16; Bit period=(512/16) (32) clocks)</p><p>|_____________ T0=FF (Ta1, Tb1, Tc1, and Td1 will be sent, 15</p><p>historical characters will be sent)</p><p></p><p>81 71 ... Secondary parameters</p><p>| |</p><p>| |__________ Td2=71 (Ta3, Tb3, and Tc3 will be sent, protocol is async</p><p>| half duplex block format)</p><p>|_____________ Ta2=81 (Mode change not allowed, Protocol is async half</p><p>duplex block format)</p><p></p><p>64 47 00 ... T=1 specific parameters</p><p>| | |</p><p>| | |_______ Tc3=00 (LRC (XOR-type) error checking to be used)</p><p>| |__________ Tb3=47 (Char wait time is 25 bit times, block wait time</p><p>| is 634.9 mSec + 11 bit times) (1 bit time=7.111</p><p>| uSec)</p><p>|_____________ Ta3=64 (Receive block size=0x64 bytes (100 bytes decimal)</p><p></p><p>44 4E 41 53 50 30 30 33 20 52 65 76 3x 3x 3x ... Historical bytes</p><p>| |</p><p>|_____ ___________________________________|</p><p>|</p><p>|_______ ASCII text: "DNASP003 Revxxx". This is just an eye-catcher</p><p>and/or ego boost for the Echo and Nagra boys. It's the</p><p>ROM version and EEPROM revision level of the firmware in</p><p>the CAM.</p><p></p><p>nn</p><p>|_____________ Checksum (all other bytes XORed together)</p><p></p><p></p><p>Just for the sake of completeness, the ATR from a ROM2-based card looks like</p><p>this:</p><p></p><p>3F ... Convention definition</p><p>|</p><p>|_____________ Inverse convention (data is inverted)</p><p></p><p>FF 95 00 FF 91 ... Initial parm setup</p><p>| | | | |</p><p>| | | | |_ Td1=91 (Ta2 and Td2 will be sent, Protocol is async</p><p>| | | | half duplex block format)</p><p>| | | |____ Tc1=FF (G-uard time=257 bits)</p><p>| | |_______ Tb1=00 (No Vpp)</p><p>| |__________ Ta1=95 (F=512, D=16; Bit period=(512/16) (32) clocks)</p><p>|_____________ T0=FF (Ta1, Tb1, Tc1, and Td1 will be sent, 15</p><p>historical characters will be sent)</p><p></p><p>81 71 ... Secondary parameters</p><p>| |</p><p>| |__________ Td2=71 (Ta3, Tb3, and Tc3 will be sent, protocol is async</p><p>| half duplex block format)</p><p>|_____________ Ta2=81 (Mode change not allowed, Protocol is async half</p><p>duplex block format)</p><p></p><p>60 47 00 ... T=1 specific parameters</p><p>| | |</p><p>| | |_______ Tc3=00 (LRC (XOR-type) error checking to be used)</p><p>| |__________ Tb3=47 (Char wait time is 25 bit times, block wait time</p><p>| is 634.9 mSec + 11 bit times) (1 bit time=7.111</p><p>| uSec)</p><p>|_____________ Ta3=60 (Receive block size=0x60 bytes (96 bytes decimal)</p><p></p><p>44 4E 41 53 50 30 30 32 20 52 65 76 30 35 32 ... Historical bytes</p><p>| |</p><p>|_____ ___________________________________|</p><p>|</p><p>|_______ ASCII text: "DNASP002 Rev052". This is just an eye-catcher</p><p>and/or ego boost for the Echo and Nagra boys. It's the</p><p>ROM version and EEPROM revision level of the firmware in</p><p>the CAM. Note ROM version 2. Also note that all ROM2s</p><p>will probably say "Rev052" because there's no more room</p><p>in their EEPROM for updates, so they're basically stuck</p><p>at rev 052 forever.</p><p></p><p>nn</p><p>|_____________ Checksum (all other bytes XORed together)</p><p></p><p>The data format (the T=1 format) is selected by bytes Td1, Td2, and Ta2.</p><p>Note that all of them agree that the data format is asynchronous half-duplex</p><p>block transfer. The baud rate is defined by byte Ta1. The upper nibble of</p><p>this byte defines parameter F (frequency) as being 512, while the lower nibble</p><p>defines parameter D (divisor) as being 16. The bit rate is found by dividing</p><p>the card's input clock frequency by the quantity (F/D) (in the case of</p><p>NagraVision cards, F/D = 512/16 = 32). If we check the clock being fed to the</p><p>smartcard by an EchoStar IRD, we find that the master clock frequency, f, is</p><p>either 4.5 MHz or 4.0 MHz, depending on the model IRD being used. Thus, the</p><p>final baud rate for communication between an EchoStar IRD and smartcard is</p><p>4,500,000/32 (140,625) bps, or 4,000,000/32 (125,000) bps . Note that this</p><p>bit rate is only necessarily 140,625 bps when the card is in an EchoStar IRD.</p><p>If the card is in a programmer that feeds a 3.6864 MHz clock to the card, the</p><p>final baud rate will be 115,200 bps (though the ATR baud rate will become</p><p>9909 bps).</p><p>The parameters such as "guard time", "character wait time", and "block wait</p><p>time" apply only to messages being sent to the card from the IRD. These</p><p>delays exist to allow the card enough time to move received data into its</p><p>internal buffers and perform any necessary decryption on the received data</p><p>before the next byte is received. It is assumed that the master device will</p><p>not need such delays, since the master device most likely has a great deal</p><p>more processing horsepower than the smartcard. In the case of the NagraVision</p><p>smartcard, a delay of at least 25 bit times (178 microseconds) is required</p><p>between bytes, and a delay of at least 635 milliseconds is required between</p><p>whole blocks.</p><p>The Tc3 byte specifies that the card is going to use LRC (Longitudinal</p><p>Redundancy Checking) as its means of error correction. This means that for</p><p>any message sent, the final byte of the message will be the XOR-sum of all</p><p>of the other bytes in the message. The other possibility for error checking</p><p>(which is required by the ISO-7816 spec) is CRC checking, which would be</p><p>selected if Tc3 was equal to 1.</p><p>The Ta3 byte specifies that the maximum message size that the card can</p><p>accept it 0x64 (100 decimal) bytes. If the receiver wants to send a message</p><p>that's longer than this, it has to break it up into smaller packets. In</p><p>NagraVision ROM version 1 cards, Ta3 was 0x60 (96 decimal). One interesting</p><p>thing to note, however, is that the first thing most IRDs I've seen do after</p><p>they reset the smartcard is request that the smartcard shrink its buffer size</p><p>to 0x58 (88 decimal) bytes.</p><p>The historical bytes are really nothing more than superfluous identification</p><p>bytes that are used by the master device to learn additional information</p><p>about the smartcard. In this case, the card sends ASCII text indicating</p><p>that it is a Nagra/Dish Network smartcard, ("DNASP"), with ROM version 3</p><p>("003"), and its current EEPROM code revision ("Revxxx"). As of this</p><p>writing, the current smartcard EEPROM revision level for EchoStar ROM3</p><p>smartcards is 372, so this text will probably read "Rev372".</p><p>Finally, the ATR is terminated by a checksum, which is the XOR-sum of all</p><p>of the other bytes in the ATR.</p><p></p><p>1.2- NagraVision's packet structure I: The ISO-specified portion</p><p></p><p>The T=1 protocol has a very specific format for the data packets. The</p><p>first 3 bytes of the packet, as well as the last byte (or the last two bytes</p><p>if CRC checking is used) of the packet are defined specifically as follows:</p><p></p><p>Byte 1: Node address byte (NAD)</p><p>Byte 2: Procedure control byte (PC<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite6" alt=":cool:" title="Cool :cool:" loading="lazy" data-shortname=":cool:" /></p><p>Byte 3: Length byte (LEN)</p><p>Last byte: Checksum (LRC)</p><p></p><p>Thus, an ISO-7816 compliant T=1 message looks like this:</p><p></p><p>NAD PCB LEN <information field> LRC</p><p></p><p>The NAD is used to route messages. The upper nibble of the NAD is defined</p><p>as the target address, and the lower nibble is defined as the source address.</p><p>In the NagraVision system, only two addresses are defined: Address 1 is the</p><p>receiver, and address 2 is the smartcard. Although 4 bits appear to be</p><p>available for addressing, in reality, only the lower 3 bits of each nibble</p><p>are available for addresses. The upper bit of each nibble is reserved for</p><p>Vpp control requests. Since the NagraVision system doesn't use these bits,</p><p>they won't be discussed here. Actually, it's also interesting to note that</p><p>the smartcarts don't do any sanity checking on the NAD...they just assume that</p><p>whatever NAD they received was the correct one and swap its nibbles when they</p><p>send a response.</p><p>The PCB is used to identify what type of data is being sent, whether it's</p><p>part of a block that's been broken up due to buffer size restrictions, if</p><p>it's a special type of control request, and so forth. There are 3 basic</p><p>formats for the PCB, as follows:</p><p></p><p>A standard "instruction" block has a PCB that looks like this:</p><p></p><p>% 0 N C 0 0 0 0 0</p><p>| | |</p><p>| | |____________ "Chain" bit. If this bit is set, it means that this</p><p>| | packet requires at least one more packet before the</p><p>| | entire message is considered "sent".</p><p>| |______________ "sequence Number" bit. This bit should toggle between</p><p>| messages. It's used to help ensure that packets were</p><p>| not missed if the chain bit is set...if the smartcard</p><p>| misses a single packet (or any odd number of packets)</p><p>| from the master, it will know that data is corrupt.</p><p>|________________ "0" in bit 7 indicates "instruction block".</p><p></p><p>A standard ISO 7816 T=1 response block from will have a PCB like this:</p><p></p><p>% 1 0 0 N 0 0 O E</p><p>|_| | | |__ Errors detected either in LRC byte or in parity.</p><p>| | |____ Other errors occurred</p><p>| |__________ "sequence Number" bit. This bit should match the N</p><p>| bit for the message to which the smartcard is</p><p>| responding.</p><p>|_______________ "10" in bits 7-6 indicates "response block"</p><p></p><p>One would ordinarily expect that the CAM responses would be sent in a</p><p>response block as defined by the ISO 7816 T=1 spec, but it turns out that</p><p>for the most part, when the CAM responds, it responds with an instruction</p><p>block of its own. And as if that deviation from the ISO spec weren't enough,</p><p>the CAM's instruction block responses don't have INS, CLA, P1, P2, or P3</p><p>bytes at the start of the information field (though the IRD's messages do).</p><p>Very odd.</p><p></p><p>Note that if a command is sent with an incorrect checksum, the CAM will</p><p>respond with one of the following messages:</p><p></p><p>12 81 00 93 -or-</p><p>12 91 00 83</p><p>| | | |_ Checksum</p><p>| | |____ Info field size (no data in this response)</p><p>| |_______ Error response: Parity/LRC error</p><p>|__________ NAD</p><p></p><p>This is an indication of an error condition either in the LRC or a parity</p><p>error with one of the bytes of the message.</p><p></p><p>Other control requests all follow a common format as follows:</p><p></p><p>% 1 1 R 0 0 0 T T</p><p>|_| | |_|</p><p>| | |___ Request type as follows:</p><p>| | 00=Resync (complete reset)</p><p>| | 01=IFS (Information Field Size)</p><p>| | 10=Abort</p><p>| | 11=WTX (Wait time)</p><p>| |____________ Request/Response (0=request, 1=response)</p><p>|_______________ "11" in bits 7-6 indicates "control request"</p><p></p><p>For an IFS request, a single byte of data will be included that tells the</p><p>target what size the source would like it to change its IFS to. Note that</p><p>although it is theoretically possible to request that the card change its IFS</p><p>to a value larger than the one specified in the ATR, the target would probably</p><p>not respond favorably to such a request. A sample IFS request (taken from an</p><p>EchoStar log) might look like this:</p><p></p><p>21 C1 01 58 89 Receiver requests card change its IFS to 0x58 bytes</p><p>12 E1 01 58 AA Card acknowledges request</p><p>|</p><p>|________ Requested IFS</p><p></p><p>Note that it is necessary to command the card to adjust its IFS after</p><p>resetting it, since the NagraVision cards default their IFS to $20 when</p><p>they are reset. As a result, any commands whose response is > $20 bytes</p><p>either have deal with a response that is chained, or the IFS has to be</p><p>adjusted upwards. Note that the cards don't do any sort of sanity checking</p><p>against the IFS on received messages. Oops.</p><p></p><p>For a WTX request, a single byte of data will be included that tells the</p><p>target what new value the source would like it to use as a block wait time</p><p>when the target is sending data to the source. This value is a multiple of</p><p>the Block Wait Time (BWT) specified by the source in its ATR.</p><p></p><p>The LEN byte is fairly straightforward: It specifies the total number of</p><p>bytes to be included in the information field.</p><p>The LRC byte is the checksum for the message. Note that this can either be</p><p>an LRC (which is what NagraVision uses) or a CRC.</p><p></p><p>1.2.1- Chained messages</p><p></p><p>When chained messages are used (either from the IRD to the CAM or from the</p><p>CAM to the IRD), the device receiving the split-up message must return a</p><p>response block to the sending device indicating that it received each block of</p><p>data correctly, so that the sending device knows that it's okay to move on to</p><p>the next block of data. The response block that must be sent depends on the</p><p>NAD and PCB of the message being ACKed, as follows:</p><p></p><p>NAD and PCB of source message Response message</p><p>----------------------------- --------------------------------</p><p>21 20 12 80 00 92</p><p>21 60 12 90 00 82</p><p>12 20 21 80 00 A1</p><p>12 60 21 90 00 B1</p><p></p><p>If the receiving device sends a response whose PCB indicates that an error</p><p>of some sort was detected, the sending device will resend the block that was</p><p>in error. If the receiving device sends some message that performs a request</p><p>of any kind, it can expect the sending device to abort the remainder of the</p><p>transmission and respond to its request.</p></blockquote><p></p>
[QUOTE="kalamar, post: 51485"] The NagraVision cards use a variant of the ISO-7816 protocol called the "T=1" or "asynchronous half-duplex block transfer" format. This format differs from the format used by DSS smartcards in that the DSS protocol (the "T=0" format) calls for the master device (the receiver or IRD) to send a 5-byte header block to the card. The card (or CAM) must then send back one of the bytes from the header (specifically, the second byte, which is the INS byte) to acknowledge receipt of the header. At this point, the IRD will either send the rest of the message to the CAM as one large packet, send the rest of the packet one byte at a time, awaiting an acknowledgment after each byte, or await the data return from the CAM. The T=1 protocol, on the other hand, is defined such that any of 7 devices all connected to the same ISO-7816 bus may initiate a transmission to any of the other devices on the bus. In addition, the message will either be sent all at once (if it is short enough to fit in the destination device's receive buffer), or broken into smaller packets if the message is too long to be sent all at once. The protocol used by the NagraVision smartcards (and in fact, by any ISO-7816 compliant smart card) is requested by the card when it is reset by a master device. After reset, the card will send a sequence of data at a fixed baud rate (input clock frequency/372...it seems like an arbitrary number, but if the input clock frequency is 3.579545 MHz, the baud rate is 9622 bps...and although 3.579545 MHz seems like a strange number, it's actually pretty common: It's the frequency used by the colorburst crystal in NTSC televisions and set-top boxes), and this data will include information about the data format the card wants to use, the baud rate at which it will want to communicate, and so on. To better understand the NagraVision cards, let's look at the ATR sent by a ROM3 Nagra card (specifically, this ATR came from an EchoStar 288-02 card, but the same ATR has been seen from cards used for ExpressVu, SkyVista, and Via Digital): 3F FF 95 00 FF 91 81 71 64 47 00 44 4E 41 53 50 30 30 33 20 52 65 76 3x 3x 3x nn If we break this ATR up into its constituent parts, we can decode it as follows: 3F ... Convention definition | |_____________ Inverse convention (data is inverted) FF 95 00 FF 91 ... Initial parm setup | | | | | | | | | |_ Td1=91 (Ta2 and Td2 will be sent, Protocol is async | | | | half duplex block format) | | | |____ Tc1=FF (Guard time=257 bits) | | |_______ Tb1=00 (No Vpp) | |__________ Ta1=95 (F=512, D=16; Bit period=(512/16) (32) clocks) |_____________ T0=FF (Ta1, Tb1, Tc1, and Td1 will be sent, 15 historical characters will be sent) 81 71 ... Secondary parameters | | | |__________ Td2=71 (Ta3, Tb3, and Tc3 will be sent, protocol is async | half duplex block format) |_____________ Ta2=81 (Mode change not allowed, Protocol is async half duplex block format) 64 47 00 ... T=1 specific parameters | | | | | |_______ Tc3=00 (LRC (XOR-type) error checking to be used) | |__________ Tb3=47 (Char wait time is 25 bit times, block wait time | is 634.9 mSec + 11 bit times) (1 bit time=7.111 | uSec) |_____________ Ta3=64 (Receive block size=0x64 bytes (100 bytes decimal) 44 4E 41 53 50 30 30 33 20 52 65 76 3x 3x 3x ... Historical bytes | | |_____ ___________________________________| | |_______ ASCII text: "DNASP003 Revxxx". This is just an eye-catcher and/or ego boost for the Echo and Nagra boys. It's the ROM version and EEPROM revision level of the firmware in the CAM. nn |_____________ Checksum (all other bytes XORed together) Just for the sake of completeness, the ATR from a ROM2-based card looks like this: 3F ... Convention definition | |_____________ Inverse convention (data is inverted) FF 95 00 FF 91 ... Initial parm setup | | | | | | | | | |_ Td1=91 (Ta2 and Td2 will be sent, Protocol is async | | | | half duplex block format) | | | |____ Tc1=FF (G-uard time=257 bits) | | |_______ Tb1=00 (No Vpp) | |__________ Ta1=95 (F=512, D=16; Bit period=(512/16) (32) clocks) |_____________ T0=FF (Ta1, Tb1, Tc1, and Td1 will be sent, 15 historical characters will be sent) 81 71 ... Secondary parameters | | | |__________ Td2=71 (Ta3, Tb3, and Tc3 will be sent, protocol is async | half duplex block format) |_____________ Ta2=81 (Mode change not allowed, Protocol is async half duplex block format) 60 47 00 ... T=1 specific parameters | | | | | |_______ Tc3=00 (LRC (XOR-type) error checking to be used) | |__________ Tb3=47 (Char wait time is 25 bit times, block wait time | is 634.9 mSec + 11 bit times) (1 bit time=7.111 | uSec) |_____________ Ta3=60 (Receive block size=0x60 bytes (96 bytes decimal) 44 4E 41 53 50 30 30 32 20 52 65 76 30 35 32 ... Historical bytes | | |_____ ___________________________________| | |_______ ASCII text: "DNASP002 Rev052". This is just an eye-catcher and/or ego boost for the Echo and Nagra boys. It's the ROM version and EEPROM revision level of the firmware in the CAM. Note ROM version 2. Also note that all ROM2s will probably say "Rev052" because there's no more room in their EEPROM for updates, so they're basically stuck at rev 052 forever. nn |_____________ Checksum (all other bytes XORed together) The data format (the T=1 format) is selected by bytes Td1, Td2, and Ta2. Note that all of them agree that the data format is asynchronous half-duplex block transfer. The baud rate is defined by byte Ta1. The upper nibble of this byte defines parameter F (frequency) as being 512, while the lower nibble defines parameter D (divisor) as being 16. The bit rate is found by dividing the card's input clock frequency by the quantity (F/D) (in the case of NagraVision cards, F/D = 512/16 = 32). If we check the clock being fed to the smartcard by an EchoStar IRD, we find that the master clock frequency, f, is either 4.5 MHz or 4.0 MHz, depending on the model IRD being used. Thus, the final baud rate for communication between an EchoStar IRD and smartcard is 4,500,000/32 (140,625) bps, or 4,000,000/32 (125,000) bps . Note that this bit rate is only necessarily 140,625 bps when the card is in an EchoStar IRD. If the card is in a programmer that feeds a 3.6864 MHz clock to the card, the final baud rate will be 115,200 bps (though the ATR baud rate will become 9909 bps). The parameters such as "guard time", "character wait time", and "block wait time" apply only to messages being sent to the card from the IRD. These delays exist to allow the card enough time to move received data into its internal buffers and perform any necessary decryption on the received data before the next byte is received. It is assumed that the master device will not need such delays, since the master device most likely has a great deal more processing horsepower than the smartcard. In the case of the NagraVision smartcard, a delay of at least 25 bit times (178 microseconds) is required between bytes, and a delay of at least 635 milliseconds is required between whole blocks. The Tc3 byte specifies that the card is going to use LRC (Longitudinal Redundancy Checking) as its means of error correction. This means that for any message sent, the final byte of the message will be the XOR-sum of all of the other bytes in the message. The other possibility for error checking (which is required by the ISO-7816 spec) is CRC checking, which would be selected if Tc3 was equal to 1. The Ta3 byte specifies that the maximum message size that the card can accept it 0x64 (100 decimal) bytes. If the receiver wants to send a message that's longer than this, it has to break it up into smaller packets. In NagraVision ROM version 1 cards, Ta3 was 0x60 (96 decimal). One interesting thing to note, however, is that the first thing most IRDs I've seen do after they reset the smartcard is request that the smartcard shrink its buffer size to 0x58 (88 decimal) bytes. The historical bytes are really nothing more than superfluous identification bytes that are used by the master device to learn additional information about the smartcard. In this case, the card sends ASCII text indicating that it is a Nagra/Dish Network smartcard, ("DNASP"), with ROM version 3 ("003"), and its current EEPROM code revision ("Revxxx"). As of this writing, the current smartcard EEPROM revision level for EchoStar ROM3 smartcards is 372, so this text will probably read "Rev372". Finally, the ATR is terminated by a checksum, which is the XOR-sum of all of the other bytes in the ATR. 1.2- NagraVision's packet structure I: The ISO-specified portion The T=1 protocol has a very specific format for the data packets. The first 3 bytes of the packet, as well as the last byte (or the last two bytes if CRC checking is used) of the packet are defined specifically as follows: Byte 1: Node address byte (NAD) Byte 2: Procedure control byte (PCB) Byte 3: Length byte (LEN) Last byte: Checksum (LRC) Thus, an ISO-7816 compliant T=1 message looks like this: NAD PCB LEN <information field> LRC The NAD is used to route messages. The upper nibble of the NAD is defined as the target address, and the lower nibble is defined as the source address. In the NagraVision system, only two addresses are defined: Address 1 is the receiver, and address 2 is the smartcard. Although 4 bits appear to be available for addressing, in reality, only the lower 3 bits of each nibble are available for addresses. The upper bit of each nibble is reserved for Vpp control requests. Since the NagraVision system doesn't use these bits, they won't be discussed here. Actually, it's also interesting to note that the smartcarts don't do any sanity checking on the NAD...they just assume that whatever NAD they received was the correct one and swap its nibbles when they send a response. The PCB is used to identify what type of data is being sent, whether it's part of a block that's been broken up due to buffer size restrictions, if it's a special type of control request, and so forth. There are 3 basic formats for the PCB, as follows: A standard "instruction" block has a PCB that looks like this: % 0 N C 0 0 0 0 0 | | | | | |____________ "Chain" bit. If this bit is set, it means that this | | packet requires at least one more packet before the | | entire message is considered "sent". | |______________ "sequence Number" bit. This bit should toggle between | messages. It's used to help ensure that packets were | not missed if the chain bit is set...if the smartcard | misses a single packet (or any odd number of packets) | from the master, it will know that data is corrupt. |________________ "0" in bit 7 indicates "instruction block". A standard ISO 7816 T=1 response block from will have a PCB like this: % 1 0 0 N 0 0 O E |_| | | |__ Errors detected either in LRC byte or in parity. | | |____ Other errors occurred | |__________ "sequence Number" bit. This bit should match the N | bit for the message to which the smartcard is | responding. |_______________ "10" in bits 7-6 indicates "response block" One would ordinarily expect that the CAM responses would be sent in a response block as defined by the ISO 7816 T=1 spec, but it turns out that for the most part, when the CAM responds, it responds with an instruction block of its own. And as if that deviation from the ISO spec weren't enough, the CAM's instruction block responses don't have INS, CLA, P1, P2, or P3 bytes at the start of the information field (though the IRD's messages do). Very odd. Note that if a command is sent with an incorrect checksum, the CAM will respond with one of the following messages: 12 81 00 93 -or- 12 91 00 83 | | | |_ Checksum | | |____ Info field size (no data in this response) | |_______ Error response: Parity/LRC error |__________ NAD This is an indication of an error condition either in the LRC or a parity error with one of the bytes of the message. Other control requests all follow a common format as follows: % 1 1 R 0 0 0 T T |_| | |_| | | |___ Request type as follows: | | 00=Resync (complete reset) | | 01=IFS (Information Field Size) | | 10=Abort | | 11=WTX (Wait time) | |____________ Request/Response (0=request, 1=response) |_______________ "11" in bits 7-6 indicates "control request" For an IFS request, a single byte of data will be included that tells the target what size the source would like it to change its IFS to. Note that although it is theoretically possible to request that the card change its IFS to a value larger than the one specified in the ATR, the target would probably not respond favorably to such a request. A sample IFS request (taken from an EchoStar log) might look like this: 21 C1 01 58 89 Receiver requests card change its IFS to 0x58 bytes 12 E1 01 58 AA Card acknowledges request | |________ Requested IFS Note that it is necessary to command the card to adjust its IFS after resetting it, since the NagraVision cards default their IFS to $20 when they are reset. As a result, any commands whose response is > $20 bytes either have deal with a response that is chained, or the IFS has to be adjusted upwards. Note that the cards don't do any sort of sanity checking against the IFS on received messages. Oops. For a WTX request, a single byte of data will be included that tells the target what new value the source would like it to use as a block wait time when the target is sending data to the source. This value is a multiple of the Block Wait Time (BWT) specified by the source in its ATR. The LEN byte is fairly straightforward: It specifies the total number of bytes to be included in the information field. The LRC byte is the checksum for the message. Note that this can either be an LRC (which is what NagraVision uses) or a CRC. 1.2.1- Chained messages When chained messages are used (either from the IRD to the CAM or from the CAM to the IRD), the device receiving the split-up message must return a response block to the sending device indicating that it received each block of data correctly, so that the sending device knows that it's okay to move on to the next block of data. The response block that must be sent depends on the NAD and PCB of the message being ACKed, as follows: NAD and PCB of source message Response message ----------------------------- -------------------------------- 21 20 12 80 00 92 21 60 12 90 00 82 12 20 21 80 00 A1 12 60 21 90 00 B1 If the receiving device sends a response whose PCB indicates that an error of some sort was detected, the sending device will resend the block that was in error. If the receiving device sends some message that performs a request of any kind, it can expect the sending device to abort the remainder of the transmission and respond to its request. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
Satellite TV receivers & systems support forums
Satellite Systems - What to Buy - What to install
How is it possible to scramble channels with multiple encryptions?
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
Accept
Learn more…
Top