0: Introductory minutae
0.0: Preface
0.1: Introduction
0.2: Where to find this FAQ
1: Glossary/Frequently used terms
1.0: Glossary (in non-alphabetic order)
2: The instruction, command, and nanocommand interpreters
2.0: How the card handles instructions, commands, and nanocommands
2.1: Examples of instructions
2.2: Examples of commands
2.3: Examples of nanocommands
3: Killing cards
3.0: 99'ing a card
3.1: 00'ing or FF'ing a card
4: Holes in the 'H' card's security
4.0: Holes in the 'H' card's security that have been closed
by DTV/NDC
4.1: The '09 hole'
4.2: The nano hole
4.3: The D5+DF/E3/F0 hole
4.4: The C9+CF/C9+D2 nano holes
4.5: Other holes that exist
5: Instruction/command/nanocommand list
5.0: Some interesting instructions/commands/nanocommands
5.1: Card type and ROM version
5.2: Card status dump
5.3: Initialize card
5.4: Set password
5.5: Get password
5.6: Dump PPV purchase list
5.7: Select public encryption key, sign packet
5.8: Select non-public encryption key, sign packet
5.9: Expiry date table
6: Updates
6.0: DTV/NDC's updates and what they affected
6.1: Updates 01 through 12
6.2: Updates 13 through 17
6.3: Updates 18 through 1A
6.4: Dummy updates 1B and 1C
6.5: Un-numbered update of 10 August, 1998
7: ECMs
7.0: DTV's ECMs against 'H' card hacks and which hacks they
affected
7.1: November, 1997
7.2: January, 1998
7.3: June, 1998
7.4: August, 1998
8: Warnings
8.0: Dangers of some of the common freeware scripts
8.0.1: 3M4M.XPL/3M.XPL/4M.XPL/4M1.XPL
8.0.2: UN0918.XPL
8.0.3: MAGIC1.SCR/MAGIC2.SCR
8.0.4: BLAZER
8.0.5: MAGIC1A.XPL
8.0.6: OTHER SCRIPTS
8.1: Other common-sense type stuff
8.1.1: Always
8.1.2: Never
8.1.3: Optional
9: How DTV can whack your card
9.1: Targeted updates
9.2: Other things DTV can do to your card besides 99ing
it
10: Q+A
11: Why people who know how the cards work are so stingy with information
12: Epilogue
12.1: Future things you may see
13: Change log
-----
0.0- Preface:
In the four or five weeks that this file has been available
to the public,
I've received a fair amount of feedback (from those who are distributing
it) that indicates that it's been well-received. For those
of you who like
this file, and who appreciate the work that it's taken to produce
it, and
particularly for those of you who took the time to make your appreciation
known, I thank you.
I'll endeavor to keep this file as accurate and as informative
as possible,
because the web really doesn't need another useless FAQ floating
around.
0.1- Introduction:
Okay...first off, there's going to be a fair number of people
who're going
to wonder why I wrote and released this FAQ. It's because
it really bugs
me to see people just sort of blindly poking away at fairly expensive
stuff
without really understanding what they're doing, and putting the
equipment
at risk while they do it. Although I won't be revealing the
deepest,
darkest secrets of the 'H' card in this FAQ, I will be explaining
how the
card's instruction, command, and nanocommand interpreters work,
discussing
a few of the instructions, and generally trying to provide a primer
on H-card
hacking.
If you're reading this FAQ hoping to find a ROM dump, a
disassembly, a
full list of instructions/commands/nanos, or anything of that nature,
then
you're going to be very disappointed, and you should probably skip
to the
last section, which I've titled, "Why people who know how the cards
work are
so stingy with information."
What you WILL find, however, is a list of terms that are
commonly thrown
around in reference to DSS cards in general, a short tutorial on
how the
instruction, command, and nanocommand interpreters work, and details
on a
few of the commands available to a would-be 'H' card hacker.
In addition,
I've thrown in a few warnings about some freeware script files
that worry
me because of the ease with which they would allow DTV to 99 a
card to which
they've been applied.
0.2- Where to find this FAQ:
The latest version of this FAQ can always be found at:
http://www.angelfire.com/ca/dsscards/dsstechfaq.html
-----
1.0- Glossary (in non-alphabetic order):
'H' card, P2 card: A series 'H' DSS smartcard. 'H'
cards contain a RISC
microcontroller core which emulates an 8051 microcontroller,
8K bytes of
masked ROM, 4K bytes of EEPROM, and 256 bytes of RAM.
In addition, 'H'
cards contain an ASIC (Application Specific Integrated Circuit)
which is
used by the microcontroller to calculate decryption seeds,
validate mess-
ages, and so forth. All 'H' cards will have a serial
number greater than
or equal to 0000 4000 0000 (see CAM ID, below). 'P2'
is short for "period
2", since this is the second generation of DSS access cards.
'F' card, P1 card: A series 'F' DSS smartcard. 'F'
cards contained a
Motorola 68HC05SC21 microcontroller core with 6K bytes of
ROM, 3K bytes of
EEPROM, and 128 bytes of RAM. This is the series of
DSS cards that pre-
ceded the 'H' card. All 'F' cards will have a serial
number less than or
equal to 0000 3999 9999 (see CAM ID, below). 'P1'
is short for "period 1",
since this is the first generation of DSS access cards.
'J' card: The rumored replacement for the 'H' card.
We don't yet know what
kind of microcontroller core or ASIC this card might have.
Most likely,
this card will also be referred to as a 'P3' card, short
for "period 3,"
since it will be the third generation of DSS access cards.
ISO Reader/ISO Programmer: A device capable of interfacing
to an ISO7816
compatible smartcard (such as a DSS card). For most
of you, this will
probably mean an MK10, MK11, MK12, etc. For some,
it will mean something
else, but it's a generic term. See also MK12/MK11/MK10/MKnn,
below.
MK12/MK11/MK10/MKnn: A MK series ISO reader/ISO programmer.
A specific
model of ISO reader/programmer designed by Paul Maxwell-King,
for which
the schematics, PCB layout, BOM (Bill of Materials), and
docs are available
as freeware on the internet. In this document, I'll
probably use the
term "MK12" to generically mean "ISO reader/ISO programmer".
.XPL file: A script file containing commands to be sent to
a smartcard
via the ISO reader/ISO programmer. .XPL is a file
extension for the
program EXPLORER, which is a DOS-based program popular for
communicating
with smartcards. In this FAQ, however, it could also
generically refer
to any similar script file, such as a .SCR file, which would
be a script
file compatible with Merlin and/or Pegasus, two WIN32-based
programs for
communicating with smartcards.
EXPLORER, Merlin, and Pegasus: Three programs often used
for communicating
with smartcards. EXPLORER is a DOS-based program,
and Merlin and Pegasus
are WIN32-based programs. All three have the ability
to use predefined
script files to perform repetitive functions, such as card
activation.
ISO7816: The specification for smartcard ICs, as set down
by the
International Standards Organization. Note that the
ISO7816 spec is
actually defined in 3 parts. ISO7816-1 defines the
physical character-
istics of the card (susceptibility to X-rays, UV radiation,
static
discharge, magnetic fields, etc., minimum bendability before
breakage,
and so forth). ISO7816-2 defines the physical interface
to the card
(contact positions and assignments, contact size, and so
on). ISO7816-3
defines the communication protocol (how to select baud rates,
how to
determine MSB-first or LSB-first communication, an so on).
A full
description of the ISO7816 spec is beyond the scope of this
document,
but it does make slightly interesting reading, so if you're
REALLY
interested in how these things work, I'd suggest locating
a copy (it
should be on the web SOMEPLACE).
DTV: DirecTV. Some of the people who want you to pay
for your DSS
satellite service.
USSB: United States Satellite Broadcasting. Some more
people who want
you to pay for your DSS satellite service.
Hughes: The corporation that first developed the DSS system
and, as it
happens, the corporation that builds the satellites that
the DSS system
uses.
NDC: News DataCom. The company that ostensibly owns
your DSS 'H' card
(check the fine print...it's not yours, it's theirs, and
they could ask
for it back any time they want). In addition to owning
the actual card,
they're also the company that wrote the code inside the
card.
99'd: A term used to describe cards that are suffering from
a specific
type of dysfunction. When DSS smartcards are first
reset, they check a
pair of bytes in their EEPROM to verify that the card is
OK for use. If
the check fails, the cards go into a tight code loop, doing
nothing but
sending the hex value 0x99 out their serial port until they
are powered
down or reset. See also the "99ing a card" section,
below. If a 99'd
card is inserted into an IRD, the IRD will usually display
a message to
the effect of "Insert a valid access card".
FF'd: A term used to describe cards that are no longer functional
in a way
that differs from that of 99'd cards. An FF'd card
is actually probably
worse off than a 99'd card. It usually isn't sending
0xFF out its serial
port, rather, its code is hanged with its serial port in
a non-idle state,
which many UARTs will misinterpret as a 0xFF (although,
technically
speaking, it's actually a BREAK condition). If an
FF'd card is inserted
into an IRD, the IRD will usually display a message to the
effect of
"Insert a valid access card".
00'd: A term used to describe cards that are no longer functional
in a way
that differs from that of 99'd cards. A 00'd card
is actually probably
worse off than a 99'd card. It usually isn't sending
0x00 out its serial
port, rather, its code is hanged with its serial port in
an idle state,
which many UARTs will report as a 0x00 (although, technically
speaking,
it's actually a "no data" condition). If a 00'd card
is inserted into
an IRD, the IRD will usually display a message to the effect
of "Insert
a valid access card".
Update: A data packet sent to the card which, if properly
authenticated
and if it contains the proper sequence number, will result
in data being
written to the card's EEPROM area. Sometimes, updates
can be bug fixes,
sometimes they can be patches to close security holes, and
sometimes,
they can just eliminate an instruction, command, or nanocommand
altogether.
Not all updates are necessarily ECMs, but it's very rare
that an update
is beneficial to an attacker.
ECM: Electronic Counter-Measure. A code update or change
in the datastream
that is intended to disrupt programming for those persons
who are not
paying full price. An ECM can be as benign as a loss
of video decoding
ability (like the loss of channel 248 et. al. that's recently
been a
problem for cards with certain versions of 3M code), or
as malignant as an
attack directed against cards with specific code changes
that causes those
cards to be 99'd (like the 99ing of cards with certain other
versions of
3M code that recently happened). Note that I'll generically
refer to
channel blackouts as the 248 blackout, because channel 248
was the first
one that was affected by this ECM. Also note that
some ECMs are in the
form of updates, but not all. For example, the Channel
248 blackout ECM
was a datastream change, but the 09 hole closure ECM that
killed most of
the wedge cards was an update. Most ECMs that cause
the card to be 99'd,
00'd, or FF'd are updates as well.
ECCM: Electronic Counter-Counter-Measure. A device
or code change designed
to prevent or reduce the effectiveness of an ECM.
Card King's Card Condom
is an example of a hardware ECCM, as are the blockers that
are built into
many wedge boards. Early blockers weren't really very
effective, because
of the limited amount of knowledge available about the various
instruc-
tions, commands, and nanocommands and how they can affect
the card. More
recent blockers are more effective, but I'd still be reluctant
to trust
them. If any of the 3M groups have software ECCMs
in their cards, they're
keeping quiet about it (as I'd expect them to), but I'd
guess that at
least one of the groups has a software-based ECCM included
with their
3M code.
IRD: Integrated Receiver-Decoder. Your DSS decoder
box. Lots of different
companies make IRDs, but they all function the same way.
In fact, most
IRDs have identical assemblies in them for functions such
as the down-
conversion and demodulation of the received satellite signal
and so forth.
IRD number: Each IRD has a unique 4-byte ID number programmed
into it at
the factory, allowing DTV to send a command to whatever
card happens to be
in your decoder, if they know the decoder's ID number.
If you subscribe
to DTV, you have to tell them your IRD's serial number (it's
on a little
sticker on the back or bottom of your IRD) when you first
sign up. The
IRD serial number is often referred to as the IRD number.
In addition,
the IRD number is used to "marry" a given CAM (see below)
to a specific
IRD; when the CAM is first inserted, the IRD queries it
for its married
IRD number. If the IRD determines that the CAM is
not yet married, it
sends an instruction to the CAM, writing its own IRD number
to the CAM's
EEPROM, "marrying" that CAM to that IRD. From that
point on, the CAM is
married to that IRD, and will not work in any other unless
it is unmarried.
If the IRD determines that the CAM is married to another
IRD, it will
usually display a message to the effect of "Insert another
access card".
Transport IC: An integrated circuit inside the IRD that sifts
through the
entire available DSS datastream and outputs only that data
that is relevant
to its IRD. The transport ID does this by monitoring
headers within the
datastream for matches on either the IRD number or the CAM
ID, or for
messages that are tagged as public. Most IRDs currently
use a transport
IC manufactured by SGS/Thomson (now called ST microelectronics).
CAM: Controlled Access Module. Your DSS access card.
CAM ID: Controlled Access Module ID. The serial number
programmed into
your DSS access card. Each DSS access card has a unique
four-byte
serial number programmed into it at the factory. This
serial number is
sometimes used by DTV (or freeware activators) to send a
command to your
card without affecting any other. The CAM ID is printed
on the back of
the CAM, with a corresponding bar code. The CAM ID
is always in the
format XXXX XXXX XXXC, where XXXXXXXXXXX (the first eleven
digits) is the
decimal representation of the four-byte CAM ID, and C is
a check digit
that is based on the other 11 digits of the CAM ID.
The only time the
check digit is used is when you call DTV to subscribe and
they ask you
what your card number is. In addition to the CAM ID,
each CAM has several
keys with varying levels of uniqueness programmed into it
at the factory.
These keys are used to verify the authenticity of messages
received by the
card. The varying levels of uniqueness allow DTV to
send commands ad-
dressed to all DSS cards, to a group of 256 or 65536 DSS
cards, or to a
single DSS card, without allowing an attacker who can view
a message
intended for a card or group other than his own to derive
a valid signa-
ture for that message for his card or a group of cards that
includes his
card.
Valid sub card/Stock card: A card which is operating with
a valid sub-
scription. DTV and USSB like valid sub cards and the
people who use them.
Virgin card: A card which has no updates on it whatsoever.
Virgin cards
are pretty hard to find these days. Most 'H' cards
coming from the factory
these days have at least the 18 updates from the 15 January,
1998 ECM
already applied to them. Those cards that came from
the factory with the
18 updates already applied can be identified physically
because they have
a little 'C' printed on them, all by itself, near the ISO
contact pads.
It stands to reason that cards will start to come from the
factory with
the 26 updates that resulted from the 18 May, 1998 ECM,
but I've neither
seen one like that nor heard of one like that. I have,
however, seen
ones with the 'C', and despite rumors and rumblings to the
contrary, I
can say with certainty that those cards have 18 updates
in them, not 23
or 26.
3M: An approach to free programming that typically involves
making a
code change to the DSS card's code so that if the card has
at least
one activated program tier, all channels can be viewed.
The term 3M
is derived from the longer name for this approach, which
is the "Three
Musketeers" approach- one for all and all for one.
Several variations
of 3M code have appeared for the 'H' cards, some of which
are the Blazer-3,
the T-3, the Predator, and the Activator Plus. A freeware
3M script file
was released, but I'd strongly recommend against using it;
it contains
debug code that DTV could use to 99 any card that's programmed
with it,
with no danger of affecting valid sub cards (see 3M4M.XPL/3M.XPL/4M.XPL/
4M1.XPL in the "Dangers of some of the common freeware scripts"
section,
below). The fact that they haven't is an indication
that they're being
kind or that they're stupid. I suspect the former.
Also, the corporation
that brought you sticky notes, which, for my money,
are the most sig-
nificant technological innovation of the last 15 years.
Wedge: A device which plugs into an IRD and into which a
CAM is plugged.
Typically, a wedge will intercept the data going to the
card and either
temporarily add a program tier for the channel to which
the IRD is tuned,
or fudge the data in some other way so as to provide free
programming.
Some common wedges are the DATS, DDT, Combo, and BOSS cards.
All wedges
stopped working after the ECM of 15 January, 1998, because
they all
relied on the 09 hole in the card's security to function.
Various new
versions of the DATS, DDT, and BOSS card have been released,
some of which
stopped functioning shortly after they were released.
Usually, this was
because they required a new "virgin" card that still had
the 09 hole open,
and they (the wedges) attempted to protect the card with
a hardware ECCM
(a blocker). With the ECM of 26 March, 1998, DTV managed
to get the up-
dates around pretty much every blocker that was running
at the time, clos-
ing the 09 hole in all those formerly virgin cards and again
rendering the
wedges inoperable. More recently, the wedge groups
have come up with
new solutions that require modified H cards in their wedges
to work.
The BOSS card group has recently introduced an update to
their cards which
they claim includes advanced ECCM technology (most likely,
a semi-intelli-
gent blocker that blocks all 40, 42, 44, and 46 instructions
that include
a nanocommand that could modify the card's EEPROM).
The vaporous and much-
discussed PASS card from Axa, though much more advanced
than the others,
is a form of wedge also.
Emulator: A device which plugs into an IRD and which acts
like a genuine
DSS card even though it isn't one. When the 'F' cards
were in service,
a freeware emulator was released which would run on an IBM-PC
compatible
computer (which would have to be plugged into the IRD via
an MK12 or other
ISO programmer board). Because of the lack of information
on the ASIC, so
far, no emulator has been released for the 'H' card.
The PASS card from
Axa is a form of emulator, in addition to being a wedge;
it has a micro-
controller that emulates most of the functions of the DSS
card, but for
those functions that depend on the ASIC, the PASS card uses
an 'H' card
that is plugged into it as a slave to get data from the
ASIC when necess-
ary. At least, that's what Axa says, and he's the
only one who would
really know, since the card isn't available yet.
Attacker: A person or device attempting to breach some form
of security.
In this case, that of the smartcard. Probably you.
Spoof: To fool a security measure of some sort into thinking
that all
conditions for valid access have been met. Also, to
provide data to
an authentication routine that makes it think it's dealing
with an
authorized user or data source, when in fact the data has
been modified
to favor an attacker.
ATR: Answer To Reset. This is part of the ISO7816-3
spec. When a
smartcard is first activated, and any time it is reset,
it has to send
a data stream out its serial port so that its host device
can determine
the card's requirements relating to communication, programming
voltages,
and so forth. The ATR allows a card to specify whether
it will communi-
cate with inverted or normal polarity data (and in addition,
whether the
data will be send MSB or LSB first), what baud rate it will
use, what
programming voltage it requires, how much current it requires
in order
to perform a programming operation, whether it will use
synchronous or
asynchronous communication, and so forth. Any ISO7816
compliant host must
be able to decode the ATR properly and adjust its communication
to suit
the card, since it is given that the amount of processing
power available
to the card is negligible compared to that of the host device.
USW: Update Status Word. An internal counter in the
'H' card that allows
the card to accept only the next intended update packet
from DTV. If the
USW is currently equal to 0x0017, then an update packet
must have a
sequence number of 0x0018 in order to be accepted by the
card. The goal
here is twofold: First, DTV wants to make sure that legitimate
updates
are never taken "out of context". Secondly, DTV can
send fake update
packets that have USW values that are out of sequence from
the USW in
valid sub cards to attack cards that have had illegitimate
updates written
to them.
CLA or Class byte: The first byte of an ISO7816-compliant
message. For
a DSS card, the class byte is 0x48 (ASCII 'H', for "Hughes",
presumably).
For British SkyTV cards, the class byte is 0x53 (ASCII 'S',
presumably
for "Sky").
INS or Instruction byte: The second byte of an ISO7816-compliant
message.
This byte can be any value, although only some values are
processed as
valid instructions by the smartcard. Note that in
the case of an 'H'
card, almost any value for the instruction byte will result
in a response
from the card, but most of them are garbage responses intended
to slow
an attacker attempting locate real instructions by brute-force
hacking.
P1 and P2: The third and fourth bytes of an ISO7816-compliant
message,
respectively. These are parameter bytes for an ISO7816-compliant
message.
Sometimes they're used, sometimes they're not, but they
must always be
present. If they're not going to be used, they're
usually both 0x00.
LEN, ILEN, Length byte, or P3: The fifth byte of an ISO7816-compliant
message. Strictly speaking, this byte tells the card
how many total
bytes will make up the transaction, but for a DSS card,
this byte is
primarily used to tell the smartcard how many more bytes
will be sent
to it to complete the message. Note that this value
can, in some cases
be larger than the actual number of bytes to follow, but
it can never be
smaller. According to the ISO7816-3 spec, this byte
should equal the
total number of bytes to be sent and received as part of
the entire trans-
action (i.e., if 6 bytes are to be sent to the card after
the header and
the host expects 3 bytes back (not counting the SW (see
below)), then LEN
should be 09).
ACK: When an ISO7816-compliant smartcard receives a valid
5-byte header
from its host, it is required to send back an acknowledgment
based on
the value of the INS byte to inform the host that it is
ready to receive
the remainder of the message. For any given value
for INS, there are
four possible values for the ACK byte, as follows:
ACK value Meaning
---------- ---------------------------------------------------------
INS
Vpp is idle, card requests that the entire packet be sent
at one time
INS xor 01 Vpp is active, card requests
that the entire packet be
sent at one time
INS xor FF Vpp is idle, card requests
that only the next byte of the
packet be sent. After each byte, the card can either
send another ACK (which is based on INS, not the packet
bytes), send the SW to terminate the packet, or become
unresponsive.
INS xor FE Vpp is active, card requests
that only the next byte of
the packet be sent. After each byte, the card can either
send another ACK (which is based on INS, not the packet
bytes), send the SW to terminate the packet, or become
unresponsive.
Note that the host device controls the application
of Vpp, so the value
of the ACK is actually also a request from the
card to the host device
to either turn Vpp on or off.
Vpp: Programming voltage. Some smartcards may use a
form of EEPROM or
PROM that requires a voltage other than 5 volts to program
it. The DSS
'H' card, however, does not.
SW: Status word. After an ISO7816-compliant smartcard
has finished pro-
cessing a packet, it must send a two-byte status word to
the host device,
informing the host device of the outcome of the transaction.
Although
many combinations are valid here (all of them will start
with 6x or 9x),
the ones that most 'H' card hackers will usually see are
90 00 and 90 80.
90 A0 is also somewhat common.
Instruction: A function that is accessed by a particular
value in the INS
byte. See below for examples.
Command: A function that is accessed by a particular value
sent as data
to the card as part of the execution of an instruction.
See below for
examples.
Nanocommand or Nano: A function that is accessed by a particular
value
sent as data to the card as part of the execution of a command.
See below
for examples.
-----
2.0- How the card handles instructions, commands, and nanocommands:
As an ISO7816-compatible device, the DSS smartcard is required
to adhere
to certain procedures regarding communication with its host device.
First, it must receive and parse a 5-byte header packet
which includes
a byte that the card must use to determine if it is the intended
target of
the message (the class byte), a byte that tells the card what type
of action
is going to be requested (the instruction byte), two parameter
bytes whose
values will vary depending on the instruction byte (the P1 and
P2 bytes),
and a byte that tells the card how many more bytes of data to expect
(the
length byte).
After receiving the 5-byte header, if the card determines
that the class
byte is indicative of a message that it should process (i.e., if
the class
byte is 0x48), it checks the remaining bytes of the message.
If the card
decides that the remaining bytes all make sense together, it sends
an ACK
to the IRD, and the IRD sends the remainder of the packet.
If, for any
reason, the card decides that the header is invalid, it may either
not
respond to the IRD or it may spew out garbage data to confuse an
attacker.
Once the card has sent its ACK, the IRD will usually
send the entire
remainder of the packet at one time. The card will deal with
the data on
an as-needed basis.
As the packet is processed, if any commands or nanocommands
are received
that would result in a change in the programming provided by the
card or in
the amount of money perceived by the card to be owed to the programming
pro-
viders, a direct modification to the card's EEPROM memory, or a
request for
the seed keys for the next few seconds of video on a given channel,
the card
will buffer the incoming data, and once it is all received, it
will calcu-
late a 5-byte value based on the received data and one of the various
authen-
tication keys stored within the card. If the card receives
a command with
a signature that matches its calculated 5-byte value, the card
will process
the commands that it has buffered. This process is the "authentication"
or "signature" process, and it involves the 09 and 0C commands.
The 09
command is used to tell the card which key it should use to calculate
the
valid signature, and is usually sent as the first command of a
given 40/42/
44/46 instruction. The 0C command is used to send the card
a signature for
comparison against the value that it has calculated, and is usually
sent
as the last command of a given 40/42/44/46 instruction. See
"Examples of
instructions, commands, and nanocommands", and "The '09 hole'",
below.
Note that not all instructions require a signature.
When providing examples of instructions, commands, and nanocommands,
I'll seperate the packet into its constituent elements, and provide
indention
that should clarify the level at which a given element is interpreted:
48 42 00 00 12
;This is an instruction, the lowest-level element
09 12 00 00
;This is a command, a level-2 element
31 12 34 56 78
;This is also a command
60
;Yet another command
BB 00
;This is a nanocommand, a level-3 element
0C 11 22 33 44 55 ;Back to command
level. Also, this command closes
;
out the packet
2.1- Examples of instructions:
An instruction is the lowest level of operation normally
available in an
'H' card. An instruction may or may not require additional
bytes to complete
its processing.
Example 1: 48 3E 00 00 00
This is the 3E instruction. It requires no additional
data, and does not
have any commands associated with it. Note that length
byte is 00, be-
cause no additional data is forthcoming for this command.
There are two
independent instruction interpreters in the 'H' card, one
ROM-based, and
one EEPROM-based. Both perform the same basic function,
and only one of
the two is ever active at a time (i.e., if the ROM-based
routine is used,
the EEPROM-based one isn't). In almost all cards,
the EEPROM-based routine
is the one that's used, because it provides a small amount
of preprocessing
that the ROM-based one doesn't, but it eventually ends up
in the ROM-based
routine, which is where the majority of instructions are
handled.
Example 2: 48 48 00 00 02
This is the 48 instruction. Note that the P3 or LEN
byte for this
instruction is 02. This is because this instruction
is used to program
data in the card, and as a result, more data will need to
be sent to the
card to complete the instruction's execution. That
data, however, must
be held in abeyance by the IRD until the card reports that
it's ready to
receive it, because of the ISO 7816 spec. For further
information on
this instruction, see section 5.4 (the "set password instruction")
2.2- Examples of commands
A command is a level 2 operation available in an 'H' card.
Only some
instructions access the command interpreter. Among these
instructions
are 40, 42, 44, and 46. In some cases, a command byte will
be followed by
a length byte so that the command interpreter knows how many bytes
to
receive in association with that command.
Example 1: 48 42 00 00 0F
09 12 00 00
31 12 34 56 78
0C 11 22 33 44 55
This is the 42 instruction. It is commonly used to
access the 'H' card's
command interpreter. Note that there is only one command
interpreter in
the 'H' card, and any instruction that has associated commands
uses that
command interpreter. However, not all commands are
valid for all
instructions.
In this case, there are three commands embedded in the 42
instruction. The
first is 09 12 00 00, the second is 31 12 34 56 78, and
the third is
0C 11 22 33 44 55. Note that the length byte is 0F,
which is the total
number of bytes that made up the three commands. Note
also that all
three of these commands are fixed-length, and so do not
have an associated
length byte (remember-the length byte always follows the
command byte, so
if any of these commands were variable length, the packet
wouldn't have
enough bytes in it to satisfy any of them: the 09 and 31
commands would
want 12 bytes, and the 0C command would want 11).
Lastly, note that almost
all command sequences will end with a 0C command.
This is because the 0C
command is the "signature" command, which the card uses
to determine
whether or not the message it just received was authentic,
and if so, it
performs the operations that were requested by that message.
Example 2: 48 42 00 00 10
09 12 00 00
08 04 12 34 56 78
0C 11 22 33 44 55
As before, this is the 42 instruction.
Again, as before, there are three commands embedded in the
42 instruction.
The first and third are the same as in the example above.
The second,
however differs. In this case, the second command
is 08 04 12 34 56 78.
This is an example of a variable-length command. In
this case, four
bytes of data are to follow, as defined by the 04 that follows
the 08.
Note that the 08 command doesn't actually do anything, but
make a good
example of a variable-length command.
2.3- Examples of nanocommands:
A nanocommand is a level 3 operation available in an 'H'
card. To the
best of my knowledge, only the 60 command has associated nanocommands.
A
nanocommand always has an associated length byte. In a virgin,
unupdated
'H' card, any value from 0x00 to 0xFF is valid as a nanocommand
(although
using non-standard values is very dangerous). In addition,
completely
virgin cards only have certain nanocommands enabled. The
first two packets
sent by DTV during the 15 January, 1998 ECM enabled the remaining
nanos. As
of 26 March, 1998 nanocommands below 0xAA were disabled, because
they al-
lowed a breach in the 'H' card's security to be exploited.
Example 1: 48 42 00 00 12
09 12 00 00
31 12 34 56 78
60
BB 00
0C 11 22 33 44 55
This is the smallest possible set of nanocommands that can
be executed.
The BB nanocommand always closes out execution of the nanocommand
inter-
preter, so it always shows up last in the list of nanocommands.
Note that
the like all nanocommands, the BB nano includes a length
byte...in this
case, 00, since the BB nano doesn't require any additional
data.
Example 2: 48 42 00 00 1C
09 12 00 00
31 12 34 56 78
60
C0 08 00 01 80 20 FF FF FF FF
BB 00
0C 11 22 33 44 55
Again, this is the 42 instruction, which is commonly used
to access the
'H' card's command interpreter (this is necessary, because
the nanocommand
interpreter is available only through command 60).
Note that this time,
however, 4 commands are included for the 42 instruction:
09 12 00 00,
31 12 34 56 78, 60, and 0C 11 22 33 44 55, with 60 being
the command that
activates the nanocommand interpreter.
This packet includes two nanocommands: C0 08 00 01 80 20
FF FF FF FF, and
BB 00. Note that both the C0 and BB nanos include
a length byte. The
length of 08 for the C0 nano indicates that 8 bytes are
to follow.
In addition, note that the nanocommands are between the 60
command and
the 0C command. Again, because the 0C command is used
to authenticate the
entire message, it is sent last.
-----
3.0- 99ing a card:
When an 'H' card is first activated or reset, there is a
routine in ROM
which checks a pair of EEPROM bytes (the 'fuse' bytes) to ensure
that the
card is valid. If the two 'fuse' bytes XORed together do
not equal 0xFF,
the card enters a tight loop where it does nothing other than send
the value
0x99 out the serial port over and over and over. A card that
is in this
state is said to be '99d'. Placing such a card into an IRD
will result in
a 'please insert a valid access card' message. A card in
this state is
basically useless, because it does not respond to any commands.
There are a few individuals and groups that have the capability
to
'un-99' a card. The operation involved in un-99ing a card
is quite complex
and isn't something that's likely to be divulged to the general
public
anytime soon.
3.1- 00'ing or FF'ing a card:
With their ECM of 9 June, 1998, DTV/NDC introduced the DSS
pirating public
at large to the 00 and FF loops. These loops were probably
familiar to most
of the guys producing fixes, since it's actually pretty easy to
get a card
into this state.
Basically, in order to 00 or FF a card, all that needs to
be done is to
corrupt the firmware in the card such that it can perform its ATR
properly,
but no longer responds properly to instructions, commands, or nanocommands.
This corruption can take the form of actual destruction or modification
of
the firmware itself, or it can be accomplished by destroying data
areas upon
which the firmware relies for proper operation (the latter is what
DTV/NDC
did with the 9 June, 1998 ECM).
Once the "normal" flow of firmware execution is disrupted,
the card's
serial data line will held in one of three states: high, low, or
hi-Z (which
is the state of the line when it is configured as an input).
Usually, the
line will be held in the hi-Z state, since that's the normal "idle"
state
of the line, unless the card is actually sending data out.
What then
happens is somewhat dependent on the hardware between the CAM and
the device
that's attempting to access it, but if the serial data line is
in a hi-Z
state, it will be biased either toward a high level or a low level
by the
external hardware. Once this happens, any device attempting
to access the
card will suddenly think it's seeing a constant high or a constant
low level
on the serial data line, and it will most likely react very badly
to it by
producing an error of some sort (usually, either a "no data received"
error, which is often misinterpreted as a 00, or a "break" condition,
which
is misinterpreted as an FF).
As of this writing, there are no confirmed reports of anyone
being able
to actually repair cards that have been 00'd or FF'd, but there
is a rumor
that Card King/NorthSat Technologies has managed to successfully
resurrect
cards that were killed in the June 9 ECM.
-----
4.0- Holes in the 'H' card's security that have been closed by DTV/NDC:
Due to the fact that the purpose of the CAM is to make sure
that persons
who own a DSS dish only get to watch the programs they're paying
for, the
CAM's firmware includes various layers of security to prevent an
unauthor-
ized person from modifying the data in the card. However,
because it is
almost impossible to test any piece of software 100%, bugs in the
software
will occasionally crop up that, if exploited properly, will allow
an attacker
to gain access to the protected data.
In this section, I'll discuss all of the security holes
that have been
exploited in the 'H' card, but later patched by DTV/NDC to prevent
their
continued use.
4.1- The '09 hole':
Virgin 'H' cards had a hole in their security which could
be exploited
using the 09 command. Basically, the way the cards work is,
when an 09
command is received, the parameters of the 09 command are used
to determine
which encryption key should be used to authenticate the message
being
received, and the ASIC is initialized to begin calculation of what
the valid
signature should be. The card contains some keys that are
"public" keys (the
same for all cards), some that are "group" keys (the same for a
group of 256
or 65536 cards), and some that are "private" keys (unique to that
individual
card). In addition, some commands are restricted so that
they will only work
if a group or private key is selected.
Once a key is selected, the signature calculation hardware
in the ASIC is
initialized, and each additional byte in the message is put through
the
authentication algorithm. If a modification to the card (either
a raw
EEPROM change, a PPV addition or removal, or a program tier addition
or
removal) would result from a received command, that command is
buffered for
later processing pending receipt of a valid signature. Once
the signature
command (0C) is received, the received signature is compared to
the calc-
ulated signature. If the two match, any buffered commands
are executed.
The problem with this was that it was possible to send a
message containing
a valid 09 command (usually 09 12 00 00), followed by a series
of commands to
perform some desired operation (for example, adding a programming
tier),
followed by a 09 command to select a public key (usually 09 10
00 00),
followed by the known valid public signature for an empty message.
What
would end up happening is that the signature calculation hardware
would get
reinitialized by the second 09 command, and because the received
signature
was valid for an empty message, the card would then process the
commands
that had been buffered following the first 09 command. This
is the premise
by which freeware activators such as CBA, DSSBUST, and CL5005 operate,
as
well as the means by which early wedge cards accomplished their
goal.
On 15 January, 1998, DTV closed the 09 hole with an update
to the 'H'
card's EEPROM-based code. What the update did was not only
reset the sig-
nature calculation algorithm when an 09 command is received, it
also reset
the internal "pending command" buffer pointers, so if a second
09 command is
received, all pending commands are lost.
A common trick for many of the freeware scripts that are
available is to
put the 09 hole back by changing DTV's update to munge the code
that checks
the command byte to see if it's 09 to decide whether or not to
reinitialize
all the buffer pointers. Usually, they change it to FE or
FF. This isn't a
particularly smart thing to leave in your card...for an explanation,
see
"Dangers of some of the common freeware scripts" section, below.
4.2- The nano hole:
Virgin 'H' cards and 'H' cards with only 18 (12 hex) updates
had a second
hole in their security. Although one of the updates on January
15th closed
the 09 hole, enough information was gleaned from the actual update
packets
to allow many individuals and groups to dump the ROM and EEPROM
of the 'H'
card, disassemble it, and understand how much of it works.
As a result, a
new hole was found which could be exploited using nanocommand values
that
NDC hadn't originally intended to be used.
On 26 March, 1998, DTV closed the nano hole with a second
round of updates
to the 'H' card's EEPROM-based code.
4.3- The D5+DF/E3/F0 hole:
With their update of 26 March, 1998, although DTV managed
to close the
original nano hole that allowed nanocommands less than $AA to be
executed,
they inadvertently opened a new hole involving a sequence of the
D5 and DF
(or D5 and E3 or D5 and F0) nanocommands. This new hole would
allow an
attacker to basically execute any code sequence they wanted to
anywhere in
memory. This hole was probably the best one possible for
hackers to use,
because there's no way in Hell DTV/NDC would've figured it out,
except that
the OPs on the #magic channel released the MAGIC1 and MAGIC2 scripts,
which
revealed the hole, and within 3 weeks, it was closed. Thanks
loads, guys.
Really.
4.4- The C9+CF/C9+D2 nano holes:
With their updates of 14 May, 1998, DTV closed a hole that
existed with the
CF nano, but for some reason, have left a related hole in the D2
nano open,
despite its having been revealed to the public. The holes
could/can be
exploited using the C9 nano followed by the CF or D2 nano.
Basically,
the C9 nano is meant to allow certain patterns of data to be written
to
the card starting at a specific EEPROM address. The CF and
D2 nanos are
meant to allow DTV to access or change the values of certain registers
within the card's CPU, but by passing a value larger than the ones
that
DTV planned to use for the D2 or CF nanos, the card could be made
to attempt
to execute code in the EEPROM area that was accessible through
the C9 nano.
The update of 14 May, 1998 added bounds-checking to the CF nano,
preventing
it from being used to transfer program control to the region where
the C9
nano does its writing.
4.5- The D0 nano hole:
With their update of 14 May, 1998, DTV also closed a hole
that allowed a
D0 nano (which was not an "official" nano) to be used to pretty
much transfer
program control to anywhere in ROM or EEPROM, or, for REALLY clever
hackers,
to allow various registers to be loaded with whatever values are
necessary
to make whatever routine the hacker wants to call work. It's
not entirely
clear whether DTV knew about the D0 hole at the time they sent
the update,
since its closure could be written off as a side effect of having
closed the
CF nano hole.
4.6- Other holes that exist:
As of this writing, there are at least four additional security
holes that
exist in 'H' cards with 26 (1A hex) updates (the total number currently
sent by DTV). I'm not going to go into details about how
many holes are
known, nor about how they work. For an explanation of why,
see the "Why
people who know how the cards work are so stingy with information"
section
at the end of this FAQ.
-----
5.0- Some interesting instructions/commands/nanocommands:
In this section, I'll be listing a few of the instructions,
commands,
and nanocommands that work with the 'H' card. Lines that
begin with a
'>' indicate data sent back from the card.
5.1- Card type and ROM version:
This command dumps information as to the ROM version
of the card, the
application for the card, and so forth.
48 02 00 00 00
>02
;INS as ACK
>48 55 54 56
;Hughes ID: "HUTV"
>02 00
;ROM version (02.00)
>48
;Class required for this card
>33
;unknown
>90 00
;Status word: normal execution
EXPLORER script:
48 02 00 00 00
R01
R04
R02
R01
R01
R02
5.2- Card status dump:
This command dumps further ID information about the
card, including
the date on which the card was activated (if any),
the USW, the
CAM ID and IRD ID, the first 12 program tiers (in
some cases, the
first 16 program tiers may be dumped), and PPV provider
information.
48 2A 00 00 00
>2A
;INS as ACK
>00 11 22 33 44 55 66 77
;CAM's internal ID
>25
;Value of fuse byte #1
>00
;Rating limit
>00
;unknown
>03 EA
;Spending limit in cents
; (03EAh=1000=$10.00)
>00
;unknown
>11 19 97
;Card activation date
>40 B0 03
;ATR historical bytes
>00 11 22 33
;CAM ID
>00 11 22 33
;IRD number XORed with CAM ID
>00 17
;USW
>00 00
;unknown
>00 00 00 00 00 00 00 00
;Program tiers 1+2
>00 00 00 00 00 00 00 00
;Program tiers 3+4
>00 00 00 00 00 00 00 00
;Program tiers 5+6
>00 00 00 00 00 00 00 00
;Program tiers 7+8
>00 00 00 00 00 00 00 00
;Program tiers 9+10
>00 00 00 00 00 00 00 00
;Program tiers 11+12
>00 00 00 00 00 00 00 00 00 00 00 00 ;PPV provider
slot 1
>00 00 00 00 00 00 00 00 00 00 00 00 ;PPV provider
slot 2
>00 00 00 00 00 00 00 00 00 00 00 00 ;PPV provider
slot 3
>00 00 00 00 00 00 00 00 00 00 00 00 ;PPV provider
slot 4
>90 00
;Status word: normal execution
EXPLORER script:
48 2A 00 00 00
R01
R08
R01
R01
R04
R03
R03
R04
R04
R02
R02
R08
R08
R08
R08
R08
R08
R0C
R0C
R0C
R0C
R02
5.3- Initialize card:
This command is used to reset the card. It will
not work if there are
any unprocessed PPV entries present in the card.
It will clear all
program tiers, all PPVs, unmarry the card, and reset
the USW to 0000.
48 3E 00 00 01
>3E
;INS as ACK
>90 00
;Status word: normal execution
EXPLORER script:
48 3E 00 00 01
R01
R02
5.4- Set password:
This command allows you to change the password stored
in the card (not
the keys that are used to calculate signatures...the
4-digit code that
your IRD uses to allow parental lock-out, spending
limit changes, and
so forth). Changing the password to a value
larger than 0x270F may cause
unpredictable results with your IRD, since the password
is stored in the
card as the hex equivalent of the 4-digit decimal
value. For example, a
value of 0x0010 for the password would result in a
password of 0016.
48 48 00 00 02
>48
;INS as ACK
00 00
;Set password to 0000
>90 nn
;Result will vary depending on
; whether command succeeded or not
EXPLORER script:
48 48 00 00 02
R01
00 00
R02
5.5- Get password:
This command allows you to read the password stored in the card.
48 52 00 00 00
>52
;INS as ACK
>04 D2
;Current password is 1234 (the sort
; of combination an idiot would have
; on his luggage)
>90 00
;Status word: normal execution
EXPLORER script:
48 52 00 00 00
R01
R02
R02
5.6- Dump PPV purchase list:
This command dumps the PPV purchase list. Each
PPV purchase has a 3-byte
entry (actually, PPV purchases internally have 8-byte
entries, but the
other 5 bytes are used to authenticate "PPV processed"
commands. The
first two bytes of each entry are the PPV ID, and
the third byte is the
status byte for that entry.
48 5E 08 0E 4B
>5E
>11 22 20
;This is a paid-for PPV, the slot
; may be reused. This PPV will not
; affect the card's ability to
; execute a 48 3E 00 00 00 packet.
>33 44 21
;This is a pending or not-paid-for
; PPV. This PPV will prevent
; the 48 3E 00 00 00 packet from
; cleaning the card.
>00 00 00
;This is a clear PPV slot
>00 00 00 00 00 00 00 00 00 00 00 00 ;PPV buys 4-7
>00 00 00 00 00 00 00 00 00 00 00 00 ;PPV buys 8-11
>00 00 00 00 00 00 00 00 00 00 00 00 ;PPV buys 12-15
>00 00 00 00 00 00 00 00 00 00 00 00 ;PPV buys 16-19
>00 00 00 00 00 00 00 00 00 00 00 00 ;PPV buys 20-23
>00 00 00 00 00 00
;PPV buys 24-25
EXPLORER script:
48 5E 08 0E 4B
R01
R03
R03
R03
R0C
;Note: These R0C's could each be
R0C
; replaced by four R03's to cause
R0C
; each PPV buy to be output on its
R0C
; own line.
R0C
R06
;Replace with two R03s to get each
; PPV buy on its own line.
5.7- Select public encryption key, sign packet:
48 42 00 00 09
>42
;INS as ACK
09 10 00 00
;Select public key
0C 11 22 33 44 55
;Sign packet (no, 11 22 33 44 55
; isn't really the correct signature
; for this packet)
>90 00
;Status word: normal execution
EXPLORER script:
48 42 00 00 09
R01
09 10 00 00
0C 11 22 33 44 55
R02
5.8- Select non-public encryption key, sign packet:
48 42 00 00 09
>42
;INS as ACK
09 12 00 00
;Select non-public key
0C 11 22 33 44 55
;Sign packet (no, 11 22 33 44 55
; probably isn't really the correct
; signature for this packet, although
; it might be, depending on the
; keys in your card)
>90 00
;Status word: normal execution
EXPLORER script:
48 42 00 00 09
R01
09 12 00 00
0C 11 22 33 44 55
R02
5.9- Expiry date table:
Jan Feb Mar Apr
May Jun Jul Aug Sep Oct Nov Dec
1996 30 31 32 33
34 35 36 37 38
39 3A 3B
1997 3C 3D 3E 3F
40 41 42 43 44
45 46 47
1998 48 49 4A 4B
4C 4D 4E 4F 50
51 52 53
1999 54 55 56 57
58 59 5A 5B 5C
5D 5E 5F
2000 60 61 62 63
64 65 66 67 68
69 6A 6B
2001 6C 6D 6E 6F
70 71 72 73 74
75 76 77
2002 78 79 7A 7B
7C 7D 7E 7F 80
81 82 83
2003 84 85 86 87
88 89 8A 8B 8C
8D 8E 8F
2004 90 91 92 93
94 95 96 97 98
99 9A 9B
-----
6.0- DTV/NDC's updates and what they affected:
In order to keep their CAMs secure, DTV/NDC occasionally
sends out update
packets that patch the firmware in the 'H' card to eliminate any
known
weaknesses in the card's security. These updates sometimes
coincide with
ECMs that are intended to render pirated cards inoperable.
In this section, you'll find a list of the updates that
DTV/NDC has sent,
the dates (or approximate dates) on which the updates first began
to appear
in the datastream, and the portions of the card's firmware that
they
affected.
6.1- Updates 01 through 12
Update date: 15 January, 1998
Number of update packets: 18 (12 hex)
First update's sequence number: 0001
Last update's sequence number: 0012 (18 decimal)
Total distinct modifications: 20 (two of the packets modified two
areas each)
Relevant changes:
09 hole closed
Nanocommands other than C6 and BB enabled
Entry point for C0 nanocommand programmed into EEPROM
Program EEPROM nanocommand modified to narrow range of valid
addresses
allowed if a key other than 2, 3, 4, or 5 is selected
Program EEPROM nanocommand modified to allow between 1 and
12 bytes of
EEPROM to be modified with a single command, rather
than requiring
exactly 4 bytes to be modified every time
Program EEPROM nanocommand modified to handle bug in 09
command which
caused card to use the global key to calculate the
signature, but Program
EEPROM nanocommand to believe that a non-global key
had been selected,
allowing access to all EEPROM areas using globally-signed
packets
57 command removed, now makes card hang rather than 99ing
card
Added some security to the C0/C6/C9/CF nano buffering routine
6.2- Updates 13 through 17
Update date: 26 March, 1998
Number of update packets: 5 (5 hex)
First update's sequence number: 0013 (19 decimal)
Last update's sequence number: 0017 (23 decimal)
Total distinct modifications: 7 (two of the packets modified two
areas each)
Relevant changes:
Nanocommands less than AA disabled
Command 57 fixed to not hang card if received, still doesn't
99
Other notes:
There are some reports that this update actually began on
27 March, 1998,
but I personally own a card that was updated to 17
on the night of the
26th. This update took longer to propagate through
the entire range of
cards (as will all future updates) because since the
updates of 15 January
keep the global key from being used to authenticate
write requests to all
but a very narrow range of EEPROM addresses, group
keys must be used
instead. Because of this, the updates are sent
to groups of 256 cards at
a time, so not all cards receive the update at the
same time.
6.3- Updates 18 through 1A
Update date: 14-18 May, 1998
Number of update packets: 3 (3 hex)
First update's sequence number: 0018 (24 decimal)
Last update's sequence number: 001A (26 decimal)
Total distinct modifications: 3
Relevant changes:
D5/DF nano hole closed
CF nano limited to operands <= 3F
D0 nano hole closed
Other notes:
This update was a direct result of the public release of
the MAGIC1 and
MAGIC2 scripts.
6.4- Dummy updates 1B and 1C
Update date: 9 June, 1998
Number of update packets: 2 (2 hex) (see below)
First update's sequence number: 001B (27 decimal)
Last update's sequence number: 001C (28 decimal)
Total distinct modifications: 2
Relevant changes:
None.
Other notes:
These two update packets were designed to allow DTV to zero
the USW
in cards whose USW had been artificially inflated.
The purpose of this
was to cause those cards to then take the 26 updates
that had been sent
as of 18 May, closing the security holes present in
cards that had been
so protected. This update was a one-time hit,
and because the cards ended
up taking the 26 "standard" updates after this update
hit them, their
USW ends up back at 001A. As a result, the next
round of updates will
once again begin with a sequence number of 001B.
6.5- Un-numbered update of 10 August, 1998
Update date: 10 August, 1998
Number of update packets: 1 (1 hex)
First update's sequence number: n/a
Last update's sequence number: n/a
Total distinct modifications: 1
Relevant changes:
Ensured that the C0 nano was checking the actual USW address
against
the update number in the nano. Apparantly, some
plastic hacks had
modified the nano so that rather than checking the
REAL USW in EEPROM,
they'd check some other area of EEPROM.
Other notes:
This update was accomplished using the D0 hole which _should_
be closed in
cards with 1A updates, so we can conclude that the
plastic hacks that
were targeted by this ECM had 0, 12, or 17 DTV updates
in them.
-----
7.0- DTV's ECMs against 'H' card hacks and which hacks they affected:
In order to make it so frustrating for a "normal" person
to use a pirate
card rather than subcribing legitimately, DTV/NDC will occasionally
send
out specific update packets that are intended to render pirate
cards in-
operable.
These update packets are only processed by specific pirate
cards, and
are ignored by valid sub cards. In order for DTV/NDC to send
such an
update packet, however, they need to have an EEPROM dump of the
pirate
card they want to attack.
7.1- November, 1997
ECM date: November ??, 1997
Total targeted updates sent: 1
Targeted hacks: East and West 3M
Casualties: All East 3Ms
Many (but not all) West 3Ms
Other notes:
The information I have on this ECM is sketchy. I'm
not entirely sure that
only one targeted update was sent as part of this ECM, but
that's what the
information I've got so far leads me to believe. If
you have further
information on this ECM, get it to TJ, and he'll see that
I get it.
7.2- January, 1998
ECM date: 15 January, 1998
Total targeted updates sent: 0 (possibly 1)
Targeted hacks:
Wedges such as the DDT, Combo, and DATS
Freeware activators using the 09 hole
Possibly East and West 3Ms again
Casualties:
Cards 99'd:
All East 3Ms that weren't hit by the November,
1997 ECM
West 3Ms prior to version 7
Cards reduced to 3 preview channels:
Wedges that were not equipped with (or were
not used with) a hardware
blocker that could block the updates
Unaffected:
T3 3M
Activator Plus 3M
Card King's 4M
Other notes:
It's not real clear to me whether the East and West 3Ms
were attacked
again during this update cycle. I've seen and
heard reports that they
were, but I've also seen and heard reports that they
were unaffected.
7.3- June, 1998
ECM date: 9 June, 1998
Total targeted updates sent: 4
Targeted hacks:
Freeware 3M/4M
Freeware Blazer
Blazer-3
West 3M
East 3M
NorthSat 3M
Wedges such as the DDT, Combo, and DATS
Freeware activators using the 09 hole
Casualties:
Cards 00'd or FF'd:
All East 3M
West 3M prior to V7
NorthSat 3M prior to V7.99
Blazer-2
Early version Blazer-3
Wedges using 09 hole
Freeware 3M/4M
Freeware Blazer
Some Predator 3M
Cards reduced to 3 preview channels:
Wedges not using the 09 hole
Freeware activated cards
Activator
Blazer-1
Activated cards in hardware blockers like VCipher
Brick Wall
Some BlackJack
Red Barron
Unaffected:
T3 3M
Activator Plus 3M
Newer Blazer-3
Most Predator 3M
Card King's 4Mv5
Wild Card
Freeware using RSP3M
7.4- August, 1998
ECM date: August 10, 1998
Total targeted updates sent: 8
Targeted hacks:
Freeware 3M/4M
Freeware Blazer
Blazer-3
West 3M
Activator
T3
Freeware activators
4M
Predator
Northsat 3M
"Matched pair" Combo wedges
Wedges such as the DDT, Combo, and DATS
Casualties:
Cards 00'd or FF'd:
West 3M prior to V8, some V8
T3 (some versions, but not all)
Blazer 2
Blazer 3 version 1 (some versions, but not all)
Blazer 3 version 2
Blazer 3 version 3
Freeware 3M/4M
Freeware Blazer
Predator version 1
NorthSat 3M v7.99 and earlier
Wedges using the 09 hole
"Matched pair" combo wedges
Cards reduced to 3 preview channels:
Activator
Blazer 1
Freeware activated cards
Wedges not using the 09 hole
Unaffected:
Blazer Plus
Card King's 4Mv5
Annhialator 3M
Some Blazer 3 version 1
Some T3
Predator version 2
West 3M newer than V8, some V8
-----
8.0- Dangers of some of the common freeware scripts:
There are a lot of scripts that are available to the public,
either via
the IRC or various web pages scattered liberally throughout the
'net.
Unfortunately, if these scripts are available to the public, they're
also
available to DTV. DTV, however, unlike most persons who might
be downloading
and using those scripts, understands exactly what the scripts are
doing and
how they're doing it. They also can see what kind of security
holes are
left in cards that have had freeware scripts added to them, and
devise ECMs
to either kill those cards (example: the 3M cards that got 99'd
because of
the 26 March, 1998 ECM) or data stream changes that will cause
those cards
to lose video (example: all the cards and wedges that have lost
channel 248
and others recently). Remember, any script that changes the
code in your
card so that it doesn't match what's in a valid sub card opens
your card up
to an attack.
I should probably mention that it's always safe to apply
a script to a card
as long as the following conditions are met:
1: The card isn't put into an IRD and exposed to DTV's datastream.
As
long as the card remains in your MK12
or whatever programmer you
happen to be using, DTV can't attack it.
2: The script can't intentionally modify the fuse bytes
in the card. If
it does, care must be taken to ensure
that the fuse bytes are both
modified at the same time, and that they're
modified properly. Im-
proper fuse byte modification results
in a 99'd card.
3: The script can't upload bad code to the card. If
bad software is
uploaded to the card, it's very possible
that the card could run amok
and destroy various areas of its EEPROM
(and there are several that
are critical to the function of the card),
or not accept or execute
instructions, commands, or nanocommands
properly.
4: The script can't modify any of the vectored entry points
within the
card to point to an address at which there
is no valid code. This
is an easy way to FF a card or get a card
into a state where it does
nothing but ATR after every command.
There are a number of scripts available right now that I
consider to be
particularly dangerous because they leave large security holes
that DTV
could use to 99 any card to which they've been applied. Below
is a list
(in no particular order) of freeware scripts that I wouldn't put
in one of
my own cards on a bet (at least, not if the bet also involved putting
the
card into an IRD).
8.0.1- 3M4M.XPL/3M.XPL/4M.XPL/4M1.XPL:
These scripts (and possibly others) are all renamed versions
of the same
basic script file, which was either leaked by someone to whom is
was given
in confidence or siphoned from the original author's hard drive.
Although
it's true that these scripts add 3M capability to a card, there
are a couple
of problems with them. First, DTV has already modified their
datastream for
several channels to prevent cards that have had the 3M portion
of this code
applied from receiving the them. Secondly, these scripts
include some debug
code that was never intended for public release which would allow
DTV to 99
any card with these scripts applied by sending the following packet:
48 44 80 20 FF
This packet will unconditionally 99 any card that's had one of these
scripts
applied to it, and will not affect any valid subscription card
in any way.
Basically, this would be a zero-downside way for DTV to whack a
bunch of
cards. If you're thinking that I'm being foolish by stating
in public the
exact procedure for killing these cards, keep in mind that it's
impossible
that DTV didn't know how to do this within 2 hours of the public
release of
these scripts. Even if you're smart enough to know how to
remove the part
of the code that would allow DTV to unconditionally 99 your card,
I'd still
recommend against using this script. For an explanation of
why, see "How
DTV can whack your card", below.
Addendum: Cards programmed with this freeware code were 00d
or FFd with an
ECM on 9 June, 1998.
8.0.2- UN0918.XPL:
Another example of a stolen script. This was a script
that was written by
Axa to allow cards that had taken the 15 January, 1998 update to
be activ-
ated using the 09 hole. The first thing it does is clean
all PPVs from the
card, then it puts the 09 hole back by changing DTV's update.
The remainder
of the script, for the most part, is only concerned with setting
up the USW
to a value that will allow it to take future DTV updates without
having them
out of context. The danger of this script is that it leaves
the 09 hole
open, so DTV could 99 any card with this script applied with the
following
packet:
48 42 00 00 19
09 1A 00 00 30 60 C0 05 00 12 80 20 FF BB 00 09
10 00 00 0C 71 3C 6B 7D FF
This packet would 99 any card that still has the 09 hole open but
whose USW
is 0011. Alternatively, DTV could send a series of packets
with sequential
sequence numbers starting at 0002, and any card with the 09 hole
still open
would be killed. Again, legitimate subscription cards would
not be affected
by this attack, only those with the 09 hole open.
8.0.3- MAGIC1.SCR/MAGIC2.SCR:
The MAGIC1 and MAGIC2 scripts that are intended to clean
PPVs from activ-
ated cards have a problem similar to that of UN0918: they would
put the 09
hole back in the card and leave the USW at a non-standard value.
In this
case, the following packet would kill cards with MAGIC1 and MAGIC2
applied:
48 42 00 00 19
09 1A 00 00 30 60 C0 05 00 34 80 20 FF BB 00 09
10 00 00 0C 71 3C 6B 7D FF
Note that in the case of both UN0918 and MAGIC1/MAGIC2, the
danger _may_
be avoidable if, after applying the scripts, you send a 48 3E 00
00 00 packet
to the card (which will reset the USW to 0000), then apply the
DTV update
simulator scripts that're available. Currently, ^T23.XPL
and ^T23.SCR,
although claiming to add all 23 updates actually only add the five
updates
sent on 26 March, 1998. To fully update the card, you need
to use the
following procedure:
1: Send a 48 3E 00 00 00 packet to clear the USW to 0000
2: Use Axa's UPD8.XPL script, which will add the 18 updates
that DTV
sent on 15 January, 1998.
3: Send another 48 3E 00 00 00 packet to again clear the
USW to 0000
4: Send either ^T23.XPL or ^T23.SCR to add the 5 updates
that DTV
sent on 26 March, 1998
8.0.4- BLAZER:
Recently, a file was leaked to the public which was an early
version of
the code for the 3M-style Blazer-3. This code was written
by Axa, and in
fact, it was leaked by the same person who leaked Axa's UN0918
file. Adding
this code to your card will make it function as a 3M card, so you'll
get all
channels, including the PPV channels. As of this writing,
no reports of
blackouts have surfaced in association with this code, but there
have been
several reports of "nag" messages appearing with this code.
Despite the
fact that this code is pretty much the same as what was in a genuine
Blazer-3 card when they were first released, I'd recommend against
using
it, and I'd also recommend against leaving genuine first-generation
Blazer-3 cards in your IRD at this point. For an explanation
of why, see
"How DTV can whack your card", below.
Addendum: Cards programmed with this freeware code were 00d
or FFd with an
ECM on 9 June, 1998. In addition, some earlier "genuine"
blazer cards were
killed, because they contained the same code.
8.0.5- MAGIC1A.XPL:
The MAGIC1A script that is intended to open the 09 hole
so that the
MAGICPPV.XPL script can be used to clean PPVs from activated cards
has the
same problem as MAGIC1.SCR: It puts the 09 hole back in the card
and leave
the USW at a non-standard value. In this case, the following
packet would
kill cards with MAGIC1A and MAGICPPV applied:
48 42 00 00 19
09 1A 00 00 30 60 C0 05 00 38 80 20 FF BB 00 09
10 00 00 0C 71 3C 6B 7D FF
Note that, as with UN0918 and MAGIC1/MAGIC2, the danger _may_
be avoidable
if, after applying the scripts, you send a 48 3E 00 00 00 packet
to the card
(which will reset the USW to 0000), then apply the DTV update simulator
scripts that're available. Currently, ^T23.XPL and ^T23.SCR,
although
claiming to add all 23 updates actually only add the five updates
sent on
26 March, 1998. To fully update the card, you need to use
the following
procedure:
1: Send a 48 3E 00 00 00 packet to clear the USW to 0000
2: Use Axa's UPD8.XPL script, which will add the 18 updates
that DTV
sent on 15 January, 1998.
3: Send another 48 3E 00 00 00 packet to again clear the
USW to 0000
4: Send either ^T23.XPL or ^T23.SCR to add the 5 updates
that DTV
sent on 26 March, 1998
8.0.6- OTHER SCRIPTS:
Recently, one or more persons have been handing out scripts
on the IRC
channel that will 99 any card that they're applied to. The
best rules to
follow are:
1: Never use any script you didn't write yourself.
2: Failing that, never use any script that didn't come from
a reputable
source, and even then, examine the script
carefully before using it.
Even the reputable sources on the IRC
are still distributing the 3M
scripts with debug code in them.
3: If you _should_ happen to use a script that kills your
card, then
be sure to warn others about it.
Allowing people to find out for
themselves is just plain mean-spirited.
8.1- Other common-sense type stuff:
As a general rule, there's several things you should always
do if you're
using a pirate card, and several others you should never do.
Most of these
are common sense, but it seems more and more these days that common
sense
isn't as common as it ought to be.
8.1.1- Always:
Always remove your CAM from your IRD when you're
not watching TV. The
updates and ECMs can only reach your card
if it happens to be in the
IRD when the packet comes through.
Always assume that your card is dead when you
turn on your IRD. This
will help alleviate the disappointment
when your card finally does die
(and it will).
Always be reasonable and courteous to your dealer.
He's taking a fair
amount of risk to bring you your card,
and if your card is dead, it's
a pretty good bet that most of the other
cards he sold are dead, too.
He's almost certainly got a whole bunch
of pissed off people breathing
down his neck, badgering him for a fix,
and your getting pissed at him
won't help the situation. DEALERS:
Note that this does not excuse you
from providing reasonable customer service.
If you've sold a card and
it's gotten killed, it's because you didn't
adequately protect it, so
it's your responsibility to fix it.
Always be suspicious of card deals that seem
too good to be true. If
you see a card for sale for $49.95, it's
a fraud.
8.1.2- Never:
Never actually call a number that appears on
your TV screen in a
message that says something like "Call
customer service, ext. 745".
These messages are just one more way that
DTV tests future ECMs and
finds pirates.
Never buy anything mail-order based on a commercial,
infomercial, or
home shopping network you see while using
your pirate card. Although
this means of flushing out pirates isn't
used too much anymore, you
never know when it'll start back up again.
Never respond to those stupid Email messages
DTV sends to your IRD.
Just erase the messages without reading
them.
Never brag to the public at large that you've
got unlimited satellite
TV and all the pay-per-view you can eat.
Not everyone believes that
you should have the right to attempt to
descramble any radio, TV, or
satellite signal that happens to stray
onto your property, and they
can and may inform DTV of your identity
if they know it.
8.1.3- Optional:
Okay, this one is purely optional, but I happen
to feel that if you're
pirating DTV's signal, it's only right
to at least pay them for a
basic subscription. My reasoning
is that, although their basic
subscription doesn't include all the PPVs
and other channels that a
3M card will get you, it does include
a whole bunch of crap that I
have no desire to ever watch. So,
I'm just subtituting things I want
for things I don't.
-----
9.0- How DTV can whack your card:
Another reason that it's dangerous to use a public script
that modifies
your card is because if DirecTV knows what changes a particular
script makes
to a card's code, they can generate an update packet that will
only be
accepted by cards that have that code change.
9.1- Targeted updates:
As we all know, the 'H' cards have an ASIC which is participates
in the
calculation of signatures for messages sent to the card, as well
as in the
calculation of seed keys for the decryption of incoming video.
They way
this works is, when the card receives a 09 nn nn nn command, it
initializes
the ASIC's registers with a given key value. Thereafter,
every byte that
is received by the card is run through a hashing algorithm, then
sent to
the ASIC, where it is applied to the seed key/signature calculation.
The
cards also include a command which allows them to apply any portion
of
their ROM or EEPROM memory to the seed/signature calculation.
This is the
means by which the channel 248 blackout was occurring; DTV knows
what area
of the card certain variations of 3M code change, so they include
that
area of memory in the seed key calculation for channel 248.
Cards that
have had a modification to that area will come up with an incorrect
result
for the seed key calculation, so the video will be gone.
This same principle can be applied in the other direction:
If DTV knows
what values a particular area of memory are changed to, they can
generate
a packet that includes a C0 nanocommand to kill the card.
They can then add
to this packet a command that causes the card to apply the modified
area of
memory to the signature, and sign the packet with a signature that
will only
be calculated as valid if the area of memory HAD been modified.
What does this mean to you? It means that unless you
know how to modify
your card to prevent DTV from making any further changes to your
EEPROM,
any change made to your card's code can be made to 99 your card.
For this
reason, I recommend strongly against using 3M code that's available
to the
public...if you have the code, DTV has the code. And if DTV
has the code,
they can target it with a 99 or worse.
9.2- Other things DTV can do to your card besides 99ing it:
Given the recent appearance of un-99ing hardware, there's
going to be
some of you who are going to leap to the conclusion that placing
your card
as risk of being 99d is no big deal, because you can just un-99
it. Keep
in mind that 99ing a card is one of the more benign things DTV
can do. They
also have the ability to erase key bits of the EEPROM, preventing
your card
from doing anything at all, or preventing an IRD from recognizing
it as a
valid card.
Keep in mind that no matter how smart you think you are,
the guys at DTV
have a big advantage over you: They've got the source code.
They know how
the card is supposed to work and how the IRDs will try to access
it. With
this knowledge, they can very easily render a card completely inoperable.
On 9 June, 1998, DTV began a new phase of their ECM campaign
with the 'H'
cards, and as I predicted in the above paragraph, DTV targeted
a whole slew
of cards for a form of ECM that causes them to enter a 00 or FF
loop. The
means by which this loop was caused isn't particularly relevant
at this
point, but what DOES matter is that those cards that DTV attacked
are in
very bad shape. The un-99ers that are starting to trickle
out into the
public aren't going to be able to do anything to help these cards.
In fact,
unless EEPROM dumps of the cards that got looped by this ECM were
kept
on file by the suppliers, it's unlikely that anyone but DTV can
restore
those cards to the state they were in before the ECM (this is not
to say
that those cards can't be recovered...they just won't be the same
as they
were before). In July of 1998, NorthSat technologies became
the first
supplier to be able to repair cards in a 00 or FF loop. Their
scheme
involves cloning a known good card's EEPROM into the card that
got looped.
There have been rumblings that it's possible to repair 00'd or
FF'd cards
without having to clone, because no card-specific information was
destroyed,
but so far, nobody's offering this service.
-----
10.0- Q+A
Okay...seeing as this is a FAQ, it's probably only right
that there should
be a section devoted to actual Q+A. If you have questions
of a technical
nature, send them to TJ at dsscards@yahoo.com, and he'll see that
I get
them. If the answer isn't already here, and if the answer
doesn't require
that sensitive information about the 'H' card be revealed, I'll
include
it in a future revision.
Q: What baud rate/settings does one use to monitor the communication
between
the IRD and the CAM using an MKxx programmer?
A: 9600 baud, 8N1. Note that when programming a CAM from
the PC using an
MKxx programmer, you'll need a 7.159 MHz clock source
for the CAM in order
to use 9600 baud.
Q: What line causes the card to reset and send an ATR?
A: With an MKxx/Phoenix style programmer, it's the RTS line.
Q: Is there a list of "special" opcodes that the card's microcontroller
supports, but that are not standard 8051 opcodes?
A: Yes, the card supports non-standard opcodes. No, I'm not
going to list
them here.
Q: How does a 3M actually work on PPV?
A: When your IRD is trying to decode the video for a given channel,
it sends
a message to the CAM, telling the CAM what the tier
code(s) is/are for the
channel, and requesting a decryption key. The
CAM, in turn, checks its
internal list of channels to which you've subscribed,
and if it finds a
matching tier in your list of subscribed tiers, it
performs a calculation
which yields the decryption key and then returns that
key to the IRD.
A 3M card works by modifying the card such that whether
a matching tier
mask exists in the EEPROM for a given channel or not,
the CAM will
calculate and return the decryption key, along with
a series of flags
that tell the IRD things like "it's okay to show this
channel, because
the user has a valid subscription (or PPV) for it,
and the rating of
this program does not exceed the currently-set ratings
limit".
Q: How did the DATS actually work on PPV?
A: PPVs, like every other DSS channel, have a tier mask associated
with them.
The only difference is that with a PPV, the tier mask
changes on either a
daily or per-showing basis. The reason for this
is so that DTV can
implement a PPV buy scheme whereby a subscriber must
phone in a request
for a PPV and pay for it up front with a credit card.
When this happens,
DTV sends a packet out to that subscriber's CAM that
tells it to add the
appropriate tier mask for the requested showing.
Later, when the sub-
scriber watches that showing, the CAM returns the
decryption key because
the tier code for the showing matches a valid tier
mask in the card.
After the showing, DTV will send out a packet that
globally deletes tier
masks for PPVs that are finished from all CAMs.
The way the DATS (and
Combo and DDT) cards worked was by "sniffing" the
datastream for a message
from the IRD requesting a decryption key. When
the DATS/Combo/DDT card
sees that message, it looks at the tier code that
the IRD says is valid
for that channel, and if it doesn't think the CAM
has an activated tier
for that channel, it would send a new message to the
CAM, telling it to
add the appropriate tier mask to its list of subscribed
tiers. Then,
it would forward the decryption request, and because
of the message that
told the card to add the tier mask, the card would
believe that it was
authorized for the channel, and happily provide the
decryption key. These
wedge boards used the 09 hole to spoof the authentication
for the "add
tier" command.
-----
11.0- Why people who know how the cards work are so stingy with information:
Finally, I'm going to wrap this whole thing up with a short
explanation of
why those of us who know a lot about how these cards work are so
stingy with
the information. A lot of people will tell you that there's
several mot-
ivating factors, some of them being:
-Money. Some of the people who've spent the time to
figure out how the
'H' cards work want to profit by their effort and
sell either modified
'H' cards, or "wedge" boards into which a modified
or unmodified 'H' card
can be inserted.
-Power. Still others who've spent the time to figure
out how the 'H'
cards work seem to get a rush from the fact that they
have a secret that
few other people share. What's odd is that there's
a lot of people
who get this same rush, even if they didn't figure
the information out
for themselves, but either were told by someone else,
or, worse,
siphoned it from someone else's hard drive.
-Fear. There are those who're afraid that if they
reveal everything they
know about the 'H' card, they'll be ostracized from
the DSS 'elite', or,
worse, have the DTV/NDC police show up at their house
with a search
warrant or a bazooka or something.
When it comes right down to it, however, almost ALL of the
individuals and
groups that have knowledge about how the cards work are reluctant
to share
it for one simple reason, no matter what anyone else says.
It's not because
we're cruel or greedy. It's because we don't want DTV to
update the cards
and make us have to figure out how to get back in all over again.
It gets
old. Speaking for myself, I don't divulge everything I know
for the simple
reason that I've got better things to do than figure out how to
get around
DTV's latest round of changes, or how to exploit holes that I've
found in
their security.
In addition, those individuals and groups who are selling
fixes don't want
DTV knowing what they did because then they'd have unhappy customers
when
they lose programming because DTV comes up with an ECM. And
no matter how
shiftless and scummy any given dealer may be, NO dealer wants to
have his
customers pissed at him, if for no other reason than a constantly
ringing
phone or a constantly full mailbox is annoying.
When DTV decides that they want to make an update to the
cards, they've
got several options open to them: They can send an EEPROM update
(they've
done this three times already), they can change their program tier
masks
(it's unclear as to whether they're currently in the process of
doing this
or not), or, worst case, they can do a card swap. Obviously,
a card swap
costs them a lot of time and money, but once the swap happens,
it'll
probably take about 6 months before the first reliable fix is available.
And with what they've learned from doing the 'F' card and the 'H'
card,
the 'J' card may just be impervious.
A couple of good examples of what can happen when DTV knows
what someone
is doing to get free programming are fairly recent. The first
is the
blackouts that were (and are again) happening on channel 248 and
others.
These channels aren't working for people who are using certain
versions of
3M code, because DTV has modified the datastream for those channels
to
include a requirement that an area of the 'H' card's EEPROM that
those
versions of 3M code use be unmodified in order for the seed keys
for the
video data to be returned. Again, DTV has been kind here.
They could have
sent a packet that just kills cards that have modified code in
a particular
area. I'm sure that in the near future, more, if not all,
channels will
have their video blacked out using this method, since it's a zero-cost,
zero-downside operation for DTV.
The second example is the recent deactivation of cards that
were activated
using freeware activators such as CBA, DSSBUST, and CL5005.
Although this
due to a routine month-end tier expiration, DTV could just as easily
have
sent a packet to each and every card for which they don't have
an activation
on record that would've removed the known freeware tiers.
If you're thinking
that DTV couldn't do this, arguing that there are millions of cards
out
there, keep in mind that the bandwidth of the DSS signal is measured
in
megabits per second. Only a fraction of that bandwidth needs
to be taken
to send deactivation packets to one million cards, if DTV is willing
to
spend a week or so on the effort.
Yet a third example is the update that happened between
May 14th and 18th,
1998. Once the hole that was created in the March 26th update
that was being
used to gain access to the cards was made public, DTV closed it.
This is a
case where it can be specifically pointed out that the hole was
closed
because it was public; NDC had no idea whatsoever that this hole
even
existed until the MAGIC1 script that used it was made public.
For the most part, up until now, DTV's object has not been
to kill cards.
They've just wanted to create a hassle for people who bought fully
activated
cards from a dealer rather than a valid DTV subscription...they
want people
to get so frustrated with having to send their card back to be
reactivated
that they'll just give up on trying to get programming for free
and sub-
scribe, but I'd bet that that philosophy isn't going to last forever.
And, at this point, we know that the days of kindness from
DTV are over.
They're no longer restraining themselves from killing cards, and
it's a safe
bet that from here on out, as soon as they've got a dump of any
new form
of 3M card that emerges, they'll target it with an ECM.
-----
12.0- Epilogue:
Well, that's about it. If you happen to see me on the
IRC and I seem to
be bashing freeware stuff, keep in mind that the reason I'm doing
it is
because for most people, adding any freeware solution to their
card is just
an invitation to get their card killed by DTV, and because I really
don't
want to have to go to the effort of figuring out how to get around
yet
another ECM. And remember: DTV is pissed now...they're just
going to keep
killing cards.
12.1- Future things you may see:
This section is basically where I'm going to list things
that I may (or
may not) add to future revisions of this file. Basically,
some of it is
pretty benign, but there are other items whose sensitivity has
to be
weighed before I can let them out into the public. Given
the speed with
which DTV responded to the public release of the MAGIC1 and MAGIC2
scripts,
I think it's pretty easy to see why every piece of knowledge that
comes my
way concerning the 'H' cards doesn't make its way to this file.
-Dumps of the various ECM and/or update packets
-Explanations of more commands (like "set/get ratings limit",
"set/get
spending limit", "set/get PPV provider info",
"add/remove tier", etc.)
-Explanations of the various values for such things as ratings
limit,
tier formats, and so forth.
-----
13.0- Change log:
Revision 06/08/98:
Added information on DTV updates of 14-18 May to the "DTV's
updates and
what they affected" section.
Added information to "'H' card", "'F' card", and "CLA" glossary
entries.
Added information on freeware Blazer to "Dangers of some
common freeware
scripts" section.
Identified release of MAGIC1 and MAGIC2 as the reason for
the 14-18 May
updates.
Revision 06/11/98:
Added the preface
Added information on the ECM of 9 June to various sections.
Added the "00'd" glossary entry.
Added the "Update" glossary entry.
Added information to the "Card status dump" instruction
section.
Added "Future things you may see" section.
Added "Change log" section.
Revision 08/15/98:
Reformatted the examples in the "how the instruction, command,
and
nanocommand interpreters work" section.
Added information on the update of 10 August to various
sections.
Added ECM log
Changed to more "traditional" FAQ format
Added "Always/never/optional" section to "Warnings"
Added warnings about MAGIC1A.XPL
Added Q+A section
Added "Spoof" glossary entry
Added additional examples to "examples of instructions"
Added additional examples to "examples of nanocommands"
Added expiry date table