Differences between revisions 1 and 3 (spanning 2 versions)
Revision 1 as of 2008-01-04 02:50:23
Size: 53584
Comment:
Revision 3 as of 2017-08-30 04:40:15
Size: 0
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
or those interested, this is good reading and should be a start.

{{{
----------------------------------
The NagraVision FAQ by StuntGuy
Revision: 12282000

Contents:

0: Openers
0.1: Introduction/About me
0.2: Where to find this FAQ
0.3: Contributors
0.4: Detractors
1: The T=1 protocol
1.1: NagraVision ATR
1.2: NagraVision's packet structure I: The ISO-specified portion
1.2.1: Chained messages
1.3: NagraVision's packet structure II: The IRD-to-CAM information field
1.4: NagraVision's packet structure III: The CAM-to-IRD information field
1.5: The status word
2: Commands
2.1: Command list
2.2: Command lengths, expected replies, and reply lengths
2.3: Command breakdown
2.3.1: CMD $00/RSP $80 Entitlement Management Message (EMM)
2.3.2: CMD $01/RSP $81 PPV Entitlement Management Message
2.3.3: CMD $02/RSP $82 MECM key update
2.3.4: CMD $03/RSP $83 Entitlement Control Message
2.3.5: CMD $12/RSP $92 Serial Number Request
2.3.6: CMD $13/RSP $93 Control Word Request (video decrypt key request)
2.3.7: CMD $14/RSP $94 Update status request
2.3.8: CMD $20/RSP $A0 Data items available request
2.3.9: CMD $21/RSP $A1 Data item request
2.3.10: CMD $30/RSP $F0 Request for callback encryption
2.3.11: CMD $31/RSP $F1 Request for callback data
2.3.12: CMD $40/RSP $70 EEPROM data space available request
2.3.13: CMD $41/RSP $71 PPV buy write
2.3.14: CMD $42/RSP $72 PPV buy link
2.3.15: CMD $55/RSP $D5 Read email
2.3.16: CMD $56/RSP $D6 Delete email
2.3.17: CMD $60/RSP $E0 Get IRD command
2.3.18: CMD $61/RSP $E1 Write IRD info
2.3.19: CMD $99/RSP $99 Anti-piracy message
2.3.20: CMD $C0/RSP $B0 CAM status request
2.3.21: CMD $C1/RSP $B1 Request for ID of updated data items
2.4: Basic command sequences
2.4.1: Finding out if the card is busy or has new information
2.4.2: Finding out what data types in the card's database have changed
2.4.3: Retrieving a specific data item from the card
2.4.4: Getting the data required to decrypt the video stream
3: EMM commands
3.1: EMM command list
3.2: EMM command breakdown
3.2.1: EMM command $00 End of EMM sequence
3.2.2: EMM command $10 Spending limit item create
3.2.3: EMM command $11 Item purchase setup
3.2.4: EMM command $12 Valid channel services item create
3.2.5: EMM command $13 PPV theme item create
3.2.6: EMM command $14 PPV number item create
3.2.7: EMM command $15 PPV service item create
3.2.8: EMM command $20 Update type $08..$0B dates
3.2.9: EMM command $21 Invalidate system info item
3.2.10: EMM command $22 Validate system info item
3.2.11: EMM command $23 Delete type $08..$0C items
3.2.12: EMM command $24 Update PPV-by-num or PPV- or sub-by-theme
3.2.13: EMM command $25 Update spending limit info
3.2.14: EMM command $26 Mark subscription item as "phoned in"
3.2.15: EMM command $2F Update subscription item info
3.2.16: EMM command $30 Kill key information
3.2.17: EMM command $31 Expire all sub items and indirection data
3.2.18: EMM command $32 Expire sub items and indir data for this sys
3.2.19: EMM command $40 Write shared addr, CAM ID, EMM addr to type 6
data, write key info to public key
3.2.20: EMM command $41 Update secondary provider information
3.2.21: EMM command $42 Update public service decrypt key/verify key
3.2.22: EMM command $43 Update public keys
3.2.23: EMM command $44 Update IRD info
3.2.24: EMM command $45 Update EMM decrypt key
3.2.25: EMM command $50 Update ZIP code
3.2.26: EMM command $51 Update time zone by ZIP code
3.2.27: EMM command $52 Update time zone
3.2.28: EMM command $53 Update blackout bytes by ZIP code
3.2.29: EMM command $54 Update blackout bytes
3.2.30: EMM command $60 2-byte EMM NOP
3.2.31: EMM command $61 Write email
3.2.32: EMM command $62 Update callback schedule
3.2.33: EMM command $63 Update callback phone #
3.2.34: EMM command $64 Encrypt IRD command
3.2.35: EMM command $80 End of EMM processing
3.2.36: EMM command $81 Master program provider activation
3.2.37: EMM command $82 End of EMM processing
3.2.38: EMM command $83 Change EMM system ID
3.2.39: EMM command $84 Desubscribe card from specified system
3.2.40: EMM command $85 Create indirection info
3.2.41: EMM command $86 Delete indirection info
3.2.42: EMM command $Fx Execute code from RAM
3.3: EMM filter command list
3.4: EMM filter command breakdown
3.4.1: EMM filter cmd $00 Filter based on CAM ID
3.4.2: EMM filter cmds $01..$20 Filter based on shared addr and bitmask
3.4.3: EMM filter cmd $3D All cards, message includes an 8-byte
signature at the end (Probably for
command $01 ECMs)
3.4.4: EMM filter cmd $3E Filter based on provider category
3.4.5: EMM filter cmd $3F No filter: Target all cards
4: 21-xx data types
4.1: Data type list
4.2: Data type breakdown
4.2.1: Data type $01 IRD information
4.2.2: Data type $02 Secondary programming provider information
4.2.3: Data type $03 Last PPV paid
4.2.4: Data type $04 Indirection information
4.2.5: Data type $05 Date information
4.2.6: Data type $06 Public service information
4.2.7: Data type $07 EMM/Verify key information
4.2.8: Data type $08 Valid channel service information
4.2.9: Data type $09 PPV-by-theme information
4.2.10: Data type $0A PPV-by-number information
4.2.11: Data type $0B PPV information
4.2.12: Data type $0C Spending limit information
4.2.13: Data type $10 Email
4.2.14: Data type $11 Misc. strings
4.3: How data is stored in the cards
4.3.1: ROM2 headers
4.3.2: ROM3 headers
7: Glossary
7.1: Glossary
8: Encryption
8.1: ECM encryption
8.1.1: The encryption algorithm
8.1.2: Correlation between DES and EDES s-boxes
8.1.3: Key permutation
8.2: EMM encryption
8.3: The valid hash
10: Firmware versions of the various E* cards
10.1: ROM2 firmware versions
10.2: ROM3 firmware versions
10.3: ROM10 firmware versions
11: Writing code for NagraVision cards
11.1: ROM2 cards
11.1.1: Bug-catcher modules
11.1.2: Hooking in a bug-catcher
11.1.3: Useful routines and memory locations
11.1.3.1: Utility routines
11.1.3.2: Database routines
11.1.3.3: Low-level routines
11.1.3.4: Encryption/decryption routines
11.1.4: Memory usage
11.1.4.1: ZP RAM
11.1.4.2: Other RAM
11.1.4.3: Tables in ROM and EEPROM
11.2: ROM3 cards
11.2.1: Bug-catcher modules
11.2.2: Hooking in a bug-catcher
11.2.3: Useful routines and memory locations
11.2.3.1: Utility routines
11.2.3.2: Database routines
11.2.3.3: Low-level routines
11.2.3.4: Encryption/decryption routines
11.2.4: Memory usage
11.2.4.1: ZP RAM
11.2.4.2: Other RAM
11.2.4.3: Tables in ROM and EEPROM
11.3: ROM10 cards
11.3.1: Bug-catcher modules
11.3.2: Hooking in a bug-catcher
11.3.3: Useful routines and memory locations
11.3.3.1: Utility routines
11.3.3.2: Database routines
11.3.3.3: Low-level routines
11.3.3.4: Encryption/decryption routines
11.3.4: Memory usage
11.3.4.1: ZP RAM
11.3.4.2: Other RAM
11.3.4.3: Tables in ROM and EEPROM
12: Epilogue
12.1: Change log
12.2: Coming in later releases
12.3: Contacting me

-----

0.1- Introduction/About me:

Okay, the first thing I'd like to say is that I'm not the one who figured
all of this stuff out. While I did figure out a lot of it, there's lots of
information here that came from other sources...their names will be included
in section 0.3: Contributors, as will the names of others who have aided
the cause. There will certainly be those who've provided information that
will be presented here who aren't credited, and when it occurs to me (or when
it's pointed out to me) that I've included information that came from an
uncredited source, I'll certainly update the FAQ to include credit where
credit is due.

Secondly, I'd just like to point out that the reason I'm doing this is just
to get all of the information that's been scattered around in one place, and
hopefully, to provide a target location for future findings. I'm not into
hacking to deprive anyone of their due revenues (in fact, I pay for my E*
subscription)...I'm in it for the entertainment. If the E*/Nagra guys can
write code that'll keep me and other hackers out of their cards, then I'm
okay with that...but they'll have to do better than 512 bytes of data tables
that do nothing but keep them from having to change an ROR into an ROL and
count the number of '1' bits they're sending. Gimme a break, guys.

Lastly, it's becoming pretty apparent that this information is not just
applicable to hacking EchoStar...EchoStar's smartcards and their conditional
access system in general were done by a company called S.A. Kudelski, which
is based in Switzerland. They call their system NagraVision, and apparently,
it's used by pay-TV providers all over the world. Hopefully, not everyone's
cards are based on the same lame code as EchoStar's, but the point here is
that much of the information you find here will be applicable to pay-TV
systems elsewhere in the world. Check your cards. If they say "Nagra", this
FAQ probably covers your cards, at least in part. In fact, as of this
writing, reports have been made of DirecTV IRDs being shipped with NagraVision
cards, indicating that DirecTV may be moving away from News Datacom's
VideoGuard system.

0.2- Where to find this FAQ:

The latest official release of this FAQ can always be found at

http://www.dishplex.com/eromcentral.shtml

0.3- Contributors:

The following is a list (in no particular order) of people who I think have
made a significant contribution to the cause of NagraVision hacking in one
form or another. Note that some of these guys aren't around anymore. One in
particular was so discouraged by the bickering in a technical discussion forum
that he left and hasn't been back since (at least, not using his original
name and demeanor).

Swiss Cheese Productions/Mr. Bean: The source of the first bit of technical
EchoStar info I found...got me on the road. Thanks, man.

Biatch: Keeps on pluggin' away at it. Nice disassembler. Worked great for
XFILE.

Stymie: PPVs in the enabler. Need I say more.

The_Crack: For the help with the FAQ. And I really appreciate someone who
doesn't flame me when I do really stupid things.

xchi and pals: You know what you provided here.

The E_r0m guys: For providing a good environment in which to work, good
information, and good sounding boards.

Code: Though you haven't been quite as up-front about it as possible, you've
been a good source of info, too. Thanks. Recent contributions include
information on the 0B data type and a broader understanding of what
some of the data being sent from the card to the IRD might represent.

BurnOutX: Provided updated (and more sensible) information about the format
for time values, as well as DST info and information about command $C0.

Wolven: For the push I needed on the $01, $41, and $42 commands.

DishFarmer: For the suggestion of adding the "status word" section, as well
as the work on the $99 command.

ZIP22: For giving DishFarmer the push on the $99 command.

tnt, DNTMATR, Star, bplus, Xilicon: For providing information about
additional NagraVision card types.

Nipper: For your very enlightening, though far too infrequent posts.

Milo: For pointing out the fact that the CAM doesn't actually use T=1
response blocks, but instead uses T=1 instruction blocks for its
messages, as well as providing an updated URL for the Keyblitz DES
document (though the updated URL is now broken, too).

The anonymous donator of the file "CA_NASP.H", which provided invaluable
information on the data types and their structures.

0.4- Detractors:

This is a message to those of you out there who can't seem to find anything
better to do with your time than whine and flame those of us who're actually
attempting to make some progress here. I'm not going to name names, but you
all know who you are. The message is this: Go away. When it comes right
down to it, there's only three reasons for you to be behaving the way you are:

1: You're working for EchoStar or Kudelski and you just want to create
dissent among those of us who're working on hacking your system. If this
is the case, your time would be much better spent working on tighter
security. And cleaner code.

2: You're an asshole who thinks the world owes you something for nothing.
If this is the case, then you're in for some serious disappointment. If
you really do want to get some programming out of all of this, then
just shut the hell up and let the rest of us do what we're good at.

3: You're a dealer and you're afraid that if other people get information on
the cards, your gravy train will go away. If that's the case, then you
should spend more time worrying about providing your customers with
quality service...they're paying a lot of money for your help and
expertise (assuming you have any), and you're doing them a disservice by
wasting energy trying to discourage others. Competition is a fact of
life...accept it and move on. Also, keep in mind that although a lot of
hackers may be able to provide their own fixes, there are a lot of
"normal" people who still need someone to sell them a set-and-forget
fix.

=============================================================================

1.1- The NagraVision ATR

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.

1.3- NagraVision's packet structure II: The IRD-to-CAM information field

For the most part, all NagraVision messages will have an information field
with a common structure. Since the IRD and the CAM have free reign over the
use of the information field of an information block, we have to make guesses
as to the definition of certain fields. Fortunately, the data is repetitive
enough that we can make some pretty good guesses.
For data being transferred from the IRD to the CAM, the information field
(not including the checksum) will always look like this:

A0 CA 00 00 CL CN DL <data0..dataDL-1> RL
|____ ____| | | | | |_ Expected length of response
| | | | |_____ Command data...total of DL bytes
| | | | will be sent, including RL
| | | |______________________ Command Data length
| | |_________________________ Command Number
| |____________________________ Command Length. Note that this
| is essentially the ISO-7816 T=0
| "P3" (or length) byte.
|____________________________________ Header: Always A0 CA 00 00. Note
that these are essentially the
ISO-7816 T=0 "CLA INS P1 P2"
bytes.

Note that there are two length bytes. Command Length (CL) and command Data
Length (DL). In actual practice, DL should always be equal to CL minus 2,
since CL counts the Command Number (CN) and the command Data Length byte (DL)
in its total. Note also that although CL and DL define the number of bytes
that will be present in the entire message, these numbers may be larger
than the overall size of the receive buffer in the smartcard. These bytes
are what the card uses to determine how many bytes the entire packet will
contain after being put back together (the LEN byte always specifies the
total number of bytes to be sent in a single burst).
Note also that the IRD indicates how much data it wants to see back from
the CAM. The Response Length byte (RL) specifies how many bytes of data the
IRD expects to see in the CAM's response, not including the 3-byte ISO-7816
header and the SW1/SW2/LRC trailer. Thus, if the IRD specifies a value of 03
for the RL, the CAM will send a total of 9 bytes back (3 bytes of ISO-7816
header, 1 byte of response type, 1 byte of data length, 1 byte of data,
2 bytes of SW1/SW2 info, and 1 byte of LRC). Note that the only time the
response length byte is actually used to determine how many bytes of data will
be sent back to the IRD is for command $21. All other commands have fixed-
length responses which they send without regard to that value of the value
of the response length byte.

1.4- NagraVision's packet structure III: The CAM-to-IRD information field

When the CAM responds to a command from the IRD, its information field
also has a rigidly defined structure. Although this structure is different
from that of the IRD-to-CAM messages, it's not too tough to figure out.
Messages sent from the CAM to the IRD look like this:

CC AL <data1..dataAL> SW1 SW2
| | | |_____|__________ Standard ISO-7816 status word.
| | | Usually 90 00. For further
| | | information about the status word,
| | | see section 1.5, "The status word".
| | |__________________ Data being returned to IRD. This
| | data field may have several data
| | elements embedded within.
| |__________________________________ Length of data field in bytes.
| This byte will usually be equal
| to RL-2 (see section 1.3 for an
| explanation of the value of RL).
|_____________________________________ Command response code. This is
related directly to the command
number for which this message is a
response. There's no apparent
set relationship between the
response code and the command no.,
but each command number does
relate to a specific response code
(see section 2: Commands)

1.5- The status word

At the end of the information field in any response from the CAM to the
IRD, there are two bytes defined by the ISO-7816 specification as the "Status
word". The status word's intent is to give the host some idea of how well the
card was able to comply with the host's request. Usually, you hope to see
a status word of "90 00", which indicates a successful completion of the
host command. In some cases, however, other responses may be seen. If the
first byte of the status word has a "6" as its upper nibble, the status word
indicates an error condition. Status words that are likely to be returned
by the EchoStar/Nagra smartcards are as follows:

SW1 SW2 Meaning
------ ------ -----------------------------------------------
63 00 Password(s) incorrect
69 82 Need password for access to backdoor commands
69 85 EEPROM data area pointer no good (Doesn't point to
an address in the $Exxx range)
69 86 Bad address in backdoor read/write memory command
6A 00 P1 and/or P2 byte incorrect
6B 00 Incorrect reference
6C FF Requested too few data bytes in $21 command
6D 00 Instruction not supported
6E 00 CLA not supported
6E 00 P1 and/or P2 byte incorrect (note: This is a bug in
the ROM3 code...in theory, this situation should
produce an SW1/SW2 of 6A 00, but it doesn't (in fact,
nothing does))
6F 00 Command not supported
90 00 Command completed successfully

==============================================================================

2.1- Known command list

Following is a list of all the commands I know about at this point. It's
a real good bet there's others, and as I find them (or as they're pointed out
to me), they'll be added here.

Cmd # Function
----- ------------------------------------------------------------------
$00 Entitlement Management Message (EMM)
$01 PPV Entitlement Management Message
$02 MECM key update
$03 Entitlement Control Message
$12 Serial Number Request
$13 Control Word Request (video decryption key request)
$14 Processing cycle request
$20 Data items available request
$21 Data item request
$30 Request for encryption of data to be sent in callback
$31 Request for data encrypted by previous command $30
$40 EEPROM data space available request
$41 PPV buy write
$42 PPV buy link
$55 Read email
$56 Delete email
$60 Get IRD command
$61 Write IRD info
$99 Anti-piracy message
$C0 CAM status request
$C1 Request for ID of updated data items

2.2- Command lengths, expected replies, and reply lengths

Most NagraVision commands are fixed-length, though there are some (like
command $03) whose length varies depending on the data in the command. In
addition, for any command that the IRD sends to the CAM, there's a specific
response that the IRD expects. In most cases, the IRD specifies the total
length of data it expects back to the response as the last byte of the
information field.

Expected Response
Cmd # Length response length
----- ------ -------- --------
$00 $53 $80 $07
$01 $56 $81 $07
$02 $53 $82 $07
$03 variable $83 $07
$12 $08 $92 $08
$13 $09 $93 $1B
$14 $08 $94 $08
$20 $0C $A0 $05
$21 $0D $A1 variable
$30 $0B $F0 $07
$31 $08 $F1 $54
$40 $08 $70 $04
$41 variable $71 $05
$42 $0F $72 $05
$55 $0B $D5 $08
$56 $0B $D6 $08
$60 $08 $E0 $44
$61 $1C $E1 $03
$99 $20 $99 $1C
$C0 $08 $B0 $08
$C1 $08 $B1 $06

2.3- Command breakdown

Here, we'll be examining each command in detail, discussing their functions,
data structures, etc.

2.3.1- Command $00/Response $80

This command is used to perform all manner of changes to the card: Updates
to code in EEPROM, attacks against hacked cards, key changes, customer
subscription, customer desubscription, and so on. The data for this command
is a 64-byte block which contains subcommands of its own. These subcommands
can be anything from "change spending limit" to "execute embedded code from
RAM". Note that although the data block is always 64 bytes long, not all of
the bytes are necessarily used. The data block is padded to 64 bytes,
probably with random data, prior to encryption. Immediately preceding the 64
byte data block is an 8-byte signature which is computed based on the
unencrypted data to confirm that the data is authentic before the commands
within are executed. In the DVB world, this type of message is referred to
as an Entitlement Management Message, or EMM. The 00 EMM is a public EMM,
though it may be directed at a specific group of cards.

Example of a $00 command and its response:

21 40 53 ; A0 CA 00 00 ;Standard header
4D ;Command length
00 ;Command
4B ;Command data length
01 01 ;System ID ($0101=EchoStar)
82 ;Key select byte (see below)
DC E9 1B 55 89 A0 D5 22 ;Signature
16 48 08 B1 A4 84 8F 2B ;Encrypted packet number 1
3B DA AC 07 A2 31 B0 83 ;Encrypted packet number 2
E2 27 5D 47 C8 27 D5 0E ;Encrypted packet number 3
7C 9C A6 51 E5 0D FE 18 ;Encrypted packet number 4
54 04 80 26 49 FC A6 71 ;Encrypted packet number 5
B2 F4 69 51 0C 22 B7 24 ;Encrypted packet number 6
BF 7E 3F 64 D0 1A BC 24 ;Encrypted packet number 7
F3 6E 88 6E 69 0F 0F 61 ;Encrypted packet number 8
05 ;Expected response length
EB ;Checksum

12 40 07 ; 80 ;Standard header, response code
03 ;Response data length
B1 01 ;Decode succeeded
04 ;Sequence number
90 00 ;SW1/SW2
F2 ;Checksum

And a decrypted 00 packet (not the one above, though):

3F 01 01 ;EMM filter: All cards whose
; primary provider has a system
; ID of 0101.
60 0A ;NOP on ROM3 cards
42 05 88 4E 25 22 BF 91 4A E4 ;Update key 0
42 85 DF 6A 21 6A 46 A8 19 2D ;Update key 1
20 00 33 00 00 00 0F 06 08 ;Update expiration + rights date
21 0C 21 0C 21 ; for all type $08..$0B data
; items with a rights ID of
; $000000 to $0C21 (1/1/9Cool
00 ;End of EMM commands

03 B5 4C 31 71 19 5A 9B ;Random data to make attack more
C0 C5 C9 32 88 03 8D B2 ; difficult
E6 8C 45 CA 20 A1 06 CD

Key select byte: This byte is used to select which EMM decrypt key set is
used (EMMKEY0 or EMMKEY1), and which parity key within that EMM key is used
(0, 1, or 2). This byte is encoded as follows:

% x x x x x x x x
| | | | | | |_|__ Parity key select: 0, 1, or 2. Note: No sanity
| | | | | | checking is done on this. (see below)
| | | | | |______ unknown
| | | | |________ Key type select bit. (see below)
| | | |__________ unknown
| | |____________ unknown
| |______________ unknown
|________________ unknown

Parity key select: These two bits allow one of three 15-byte parity keys
within the selected EMM key to be used. No sanity checking is done on this
data, so a value of 3 is also valid, and causes the verify key plus the first
7 bytes of the EMM key to be used as the parity key.
Key type select bit: This bit is used to match against the "key type" byte
in the type $07 data item. If this bit is clear, a key type byte of 0 will
be matched, if it is set, a key type byte of $01 will be matched.

As you can see, the first $28 bytes of decrypted data are EMM commands (see
section 3, EMM commands), and the last $18 bytes are just random data that
exists only to reduce the chances of two encrypted 00 commands looking even
remotely alike.

2.3.2- Command $01/Response $81

Command 01 is a PPV purchase-related EMM message. Like command $00, it
contains a 64-byte encrypted data field, which contains the EMM commands
required to enable the viewing of the purchased PPV (ie., add PPV data
item). The format for this command is as follows:

21 00 53 ; A0 CA 00 00 ;Standard header
4D ;Command length
01 ;Command
4B ;Command data length
01 01 ;System ID
82 ;Key select byte
00 00 00 00 00 00 00 00 ;Unused
00 11 22 33 44 55 66 77 ;Encrypted packet number 1
88 99 AA BB CC DD EE FF ;Encrypted packet number 2
00 11 22 33 44 55 66 77 ;Encrypted packet number 3
88 99 AA BB CC DD EE FF ;Encrypted packet number 4
00 11 22 33 44 55 66 77 ;Encrypted packet number 5
88 99 AA BB CC DD EE FF ;Encrypted packet number 6
00 11 22 33 44 55 66 77 ;Encrypted packet number 7
88 99 AA BB CC DD EE FF ;Encrypted packet number 8: valid hash
05 ;Expected response length
80 ;Checksum

12 00 07 ; 81 ;Response type
03 ;Response data length
B1 01 ;Decode succeeded
05 ;Sequence number
90 00 ;SW1/SW2
B2 ;Checksum

2.3.3- Command $02/Response $82

Command 02 is the command used to update MECM decryption keys in the CAM.
MECM decryption is used in conjunction with the standard command $03
decryption: After the control words in a given $03 command are decrypted,
they are XORed with an 8-byte hunk of the MECM key before re-encrypting
them and returning them to the IRD. The format for the $02 command is as
follows:

21 00 53 ; A0 CA 00 00 ;Standard header
4D ;Command length
02 ;Command
4B ;Command data length
01 01 ;System ID
01 ;Key select byte
00 00 00 00 00 00 00 00 ;Unused
00 11 22 33 44 55 66 77 ;Encrypted packet 1
88 99 AA BB CC DD EE FF ;Encrypted packet 2
00 11 22 33 44 55 66 77 ;Encrypted packet 3
88 99 AA BB CC DD EE FF ;Encrypted packet 4
00 11 22 33 44 55 66 77 ;Encrypted packet 5
88 99 AA BB CC DD EE FF ;Encrypted packet 6
00 11 22 33 44 55 66 77 ;Encrypted packet 7
88 99 AA BB CC DD EE FF ;Encrypted packet 8: valid hash
05 ;Expected response length
08 ;Checksum


Once the ciphertext block is decrypted, the computed hash value of the
first 7 blocks of decrypted data is compared to the valid hash, which is
stored in the last 8 bytes of encrypted data. If the valid hash matches,
17 bytes of the decrypted data are then used as MECM decrypt data. The
structure of the data within the encrypted block is as follows:

00 00 ;Probably system ID
00 ;Probably key select byte
01 ;MECM data start address (see below)
00 11 22 33 44 55 66 77 ;MECM key data (16 bytes)
88 99 AA BB CC DD EE FF
00 00 00 00 ;Unknown, probably random data
00 00 00 00 00 00 00 00 ;Unknown, probably random data
00 00 00 00 00 00 00 00 ;Unknown, probably random data
00 00 00 00 00 00 00 00 ;Unknown, probably random data
00 00 00 00 00 00 00 00 ;Unknown, probably random data
01 23 45 67 89 AB CD EF ;Valid hash

MECM start address: This byte tells the CAM the addresses within the full
256-byte MECM key the 16-byte block of data included with this command $02
represents. It appears as though the CAM is able to hold 16 only bytes of
the full 256 byte MECM key, so the MECM start address is used to tell the CAM
which byte of the overall key is the first one it has in its 16-byte buffer.
So, for example, a MECM start address of 0x12 specifies that the 02 command
includes bytes 0x24 thru 0x33 of the entire MECM key.
Since the CAM always remembers only 16 bytes of the overall MECM key, the 03
commands that intend to use the MECM data also include a start address which
tells the CAM the address within the full 256-byte MECM key at which the
8-byte block the CAM should XOR a decrypted control word with starts. Note
that the start address requested by a 03 command can only ever be larger in
magnatude than the start address in the most recent 02 command by a value of 4
(ie., if the start address in the most recent 02 command was 0x12 (MECM bytes
0x24 thru 0x33), the maximum start address allowed in a 03 command is 0x16
(MECM bytes 0x2C thru 0x33).

2.3.4- Command $03/Response $83

This command is used to prime the card to return video decryption keys to
the IRD. Contained within this command's encrypted packets are information
pertaining to the program tier the user is attempting to view, the correct
audio and video decryption keys for the channel, current date and time, and so
forth. When a card receives a $13 command, it will re-encrypt the decryption
keys using the IRD's 8-byte key and return them to the IRD if it (the card)
believes that the program tier that the user is attempting to watch is one for
which they are authorized.
In addition to information about the program that the user is attempting to
watch, the 03 command contains information about the encryption method used,
how many encrypted video keys are present, and so forth. For a detailed
explanation of the control bytes, see the breakdown of the decrypted packets,
below.

Example of a $03 command, both encrypted and decrypted, and its response:

21 00 35 ; A0 CA 00 00 ;Standard header
2F ;Instruction length
03 ;Command
2D ;Command data length
01 01 ;System ID
10 ;ECM type
29 ;Data field length
05 ;Key select byte (see below)
12 D4 70 4D 34 FB 3C DF ;Valid hash (signature)
90 DD 23 D3 7B A9 79 DC ;Encrypted packet 1
CF DE 68 4E A4 43 0F 1B ;Encrypted packet 2
F5 E0 9B B3 30 58 FB 75 ;Encrypted packet 3
4F 3E AB EB 4C 8F F0 6F ;Encrypted packet 4
05 ;Expected response length
29 ;Checksum

12 00 07 ; 83 ;Response code
03 ;Response data length
B1 01 ;Decode succeeded
03 ;Sequence number
90 00 ;SW1/SW2: Successful completion
B6 ;Checksum

Here's what the data in the encrypted packets looks like after decryption:

10 ;Control word control byte (see below)
80 ;MECM index byte 1 (see below)
39 31 33 9D 31 32 35 98 ;Control word 1
80 ;MECM index byte 2 (see below)
34 30 32 96 34 35 34 9D ;Control word 2
24 ;Tier info tag byte: Group access
01 ;Group ID
0D 86 ;Current date
B3 54 ;Current time
00 ;End of standard data marker
55 55 55 55 55 55 ;Pad bytes to make encrypted data come
;out to a multiple of 8 bytes

Key select byte: This byte is used to tell the $03 decode routine which
public key (if any) was used to encrypt the data in the 03 command. If the
low 3 bits of this byte are "101", then the CAM uses the standard E* DES-like
decrypt on the data. If the low 3 bits are "111", the CAM doesn't perform any
decryption on the data at all. If the low 3 bits are anything other than
"101" or "111", the CAM discards the packet. Bit 4 of this byte indicates
which public key was used: 0 for key 0, 1 for key 1. Bit 3 is a flag which
selects which verify key is used to compute the signature for the message.
Control word control byte: If this byte is $10, then the CAM knows that two
control words are present. If this byte is $11, then the CAM only tries to
decrypt the first control word, but it returns it as the second return word
in the next command 13.
MECM index byte: If bit 7 of this byte is clear, then before the CAM
re-encrypts the control words for return to the IRD, it XORs them with a
sequence of bytes that come from a $02 command. The $02 command includes 16
bytes of MECM data and an address byte which tells the CAM which 16 bytes of
the 256-byte MECM key the CAM currently knows about. The 03 command's MECM
index byte specifies the address within the full 256-byte MECM key of the
first of 8 bytes to be XORed with its control word. So, for example, a MECM
index byte in a 03 command with a value of 0x14 specifies that bytes 0x28 thru
0x2F (0x14*2 thru (0x14*2)+7) are to be XORed with the decrypted control words
before re-encryption and return to the IRD. If the index byte in the 03
command refers to any data that is outside the range of MECM data currently
known to the CAM, the CAM will invalidate its current MECM data and set the
"CAM suggests $02 command" bit in the C0 status response, prompting the IRD to
provide it with the most recent 02 command it (the IRD) knows about.

Note that the above version of the 03 packet is a "group access" packet,
which is usually used to provide access to free informational channels (with
programs like Charlie Chat). An example of a $03 command that requires a
specific program tier might look like this:

21 00 3D ; A0 CA 00 00 ;Standard header
37 ;Instruction length
03 ;Command
35 ;Command data length
01 01 ;System ID. $0101=EchoStar
10 ;Control word tag byte
31 ;Data field length
05 ;Key select byte
B8 2E A0 FF B4 F9 2C 2F ;Valid hash (signature)
3C 4F C7 CB 26 E1 FF 3E ;Encrypted packet 1
C0 4D F2 6F 37 C3 22 8D ;Encrypted packet 2
4B 42 B2 BC 99 15 3B D4 ;Encrypted packet 3
5D 95 0D 0A 93 57 0F 7A ;Encrypted packet 4
69 50 D7 4E 2C B5 ED CB ;Encrypted packet 5
05 ;Expected response length
A6 ;Checksum

12 00 07 ; 83 ;Response code
03 ;Response data length
B1 01 ;Decode succeeded
03 ;Sequence number
90 00 ;SW1/SW2: Successful completion
B6 ;Checksum

And the decrypted data...

10 ;Control word tag byte
80 ;MECM index byte 1
33 36 34 9D 34 30 35 99 ;Control word 1
80 ;MECM index byte 2
36 31 32 99 30 33 39 9C ;Control word 2
20 ;Tier info tag byte: Straight sub
00 1D ;Tier ID
80 00 ;Component (?)
FF ;Theme (?)
00 ;Level (?)
0D 8C ;Program start date (12 Dec 1998)
88 00 ;Program start time (17:00:00 GMT)
0D 8C ;Current date (12 Dec 1998)
92 16 ;Current time (18:16:22 GMT)
00 ;End of data marker
55 55 55 55 55 ;Pad bytes

Time-of-day info: The E* time of day seems to be encoded as follows:

Date Time
---------------------------- ------------------------------
Bits 0..4=day 1-31 Bits 0..4=second/2 0-29
Bits 5..8=month 1-12 Bits 5..10=minute 0-59
Bits 9..15=year-1992 0-127 Bits 11..15=hour 0-23

Further notes about the 03 packet: The two control words, the MECM control
bytes, and the control word control byte must ALWAYS be located at the start
of the encrypted data as shown above. The NagraVision CAM is hard-coded to
expect the control word data and associated control bytes to be in those
locations.

Within the ECM, lots of commands and filters are possible. The first
variable is the ECM type:

21 00 35 ; A0 CA 00 00 ;Standard header
2F ;Instruction length
03 ;Command
2D ;Command data length
01 01 ;System ID
>>> 10 ;ECM type
29 ;Data field length
05 ;Key select byte (see below)
12 D4 70 4D 34 FB 3C DF ;Valid hash (signature)
90 DD 23 D3 7B A9 79 DC ;Encrypted packet 1
CF DE 68 4E A4 43 0F 1B ;Encrypted packet 2
F5 E0 9B B3 30 58 FB 75 ;Encrypted packet 3
4F 3E AB EB 4C 8F F0 6F ;Encrypted packet 4
05 ;Expected response length
29 ;Checksum

Valid ECM types are:

Type Description
---- ---------------------------------------------------------
$10 Double control-word ECM
$11 Even control-word-only ECM
$12 Odd control-word-only ECM

ECM types $10, $11, and $12 all have packets that should look pretty much
the same, except that type 10 contains even and odd control words, type 11
only contains an even control word, and type 12 only contains an odd control
word. In addition to the control words, ECM types 10, 11, and 12 also can
contain a variety of data filtering fields. These fields allow the CAM to
decide if the user is authorized to view the program of not. Below is an
example of a decrypted type 10 ECM:

10 ;Control word control byte (see below)
80 ;MECM index byte 1
39 31 33 9D 31 32 35 98 ;Even control word
80 ;MECM index byte 2 (see below)
34 30 32 96 34 35 34 9D ;Odd control word
>>> 24 ;Filter type byte
01 ;Access group ID
0D 86 ;Current date (6 Dec 1998)
B3 54 ;Current time (22:26:20 GMT)
00 ;End of standard data marker
55 55 55 55 55 55 ;Pad bytes to make encrypted data come
;out to a multiple of 8 bytes

In this case, the ECM command is 24, which indicates group-controlled
access. Valid ECM commands and their formats are:

Type Description/Format
---- ----------------------------------------------------------
$20 Straight subscription
20 ;Filter type
01 02 ;Tier ID
01 02 ;"Component"
01 ;Theme (program type?)
01 ;Level (Rating?)
01 02 ;Program start date
03 04 ;Program start time
01 02 ;Current date
03 04 ;Current time

$21 Pay-per-view (see notes below)
21 ;Filter type
01 02 03 ;PPV ID
01 ;"Watched" odometer threshold (see
; below)
01 02 ;PPV token cost in units (hex) per ECM
03 ;PPV token cost in 1/100 units per ECM
01 02 ;PPV cash cost in units (hex) per ECM
03 ;PPV cash cost in 1/100 units per ECM


$22 Program type blackout (see notes below)

$23 Regional blackout (see notes below)

$24 Group access
24 ;Filter type
01 ;Group ID
01 02 ;Current date
03 04 ;Current time

For ECM command 21, it appears that various charge options are available:
The program provider can choose to charge once for the impulse buy and leave
it at that (which is the most common mode of usage), or allow "tokens" to be
bought which can be deducted in varying amounts when the user tunes to the
event. In addition, both cash and tokens can be applied per unit of time, so
the longer the user watches, the more they have to pay.
The "watched" odometer threshold tells the card how many ECMs may be
processed for a given PPV data item before that PPV is considered "watched"
and must therefore be charged to the customer.
Note that although ECM command $21 contains sufficient information to
validate an ECM, it will usually be preceded by an ECM command $20 which
provides a tier ID, component, theme, level, and time/date info. Presumably,
this is so that employees of program providers can have subscriptions in their
cards which allow them to watch any PPV they want at any time.

The two blackout ECM commands ($22 and $23) allow the card to decide whether
or not to return the control words for a given channel based on the blackout
information stored in the type $06 data item whose system ID high matches the
system ID high of the ECM. Note that if a blackout ECM command is used, no
tier ID is needed. The two blackout ECM commands are formatted as follows:

22 ;ECM command: Program type blackout
41 ;Blackout category (see below)
01 ;Program type

23 ;ECM com
}}}