557 lines
29 KiB
Plaintext
557 lines
29 KiB
Plaintext
|
||
Some technical details about Videocrypt
|
||
---------------------------------------
|
||
|
||
Markus Kuhn -- 1994-08-02
|
||
|
||
|
||
In this file, I'll collect some of the details known or assumed about
|
||
the Videocrypt pay-TV access control system. Consider it as some kind
|
||
of frequently asked questions list with answers about the system.
|
||
|
||
|
||
1 Basic principle
|
||
|
||
Videocrypt encodes the TV image by cutting each line of the image in
|
||
two pieces at some cut point and then exchanges these two line
|
||
fragments in the broadcasted pictures. E.g. if a line like
|
||
|
||
0123456789
|
||
|
||
passes the encoder, the output might look like
|
||
|
||
4567890123
|
||
|
||
where the digits represent the pixels of the image. There are 256
|
||
possible cut points and there are no cut points directly near the image
|
||
border (the miniumum distance from the margin is about 12-15% of the
|
||
image width) which is the reason why you sometimes still can see
|
||
vertical patterns even on an encrypted image. The sound is currently
|
||
not encrypted.
|
||
|
||
Several times per second, a computer at the broadcasting station
|
||
generates a 32 byte long message which is broadcasted encoded together
|
||
with forward error correction information in the first invisible lines
|
||
of the TV signal similar to teletext. About every 2.5 seconds, one of
|
||
these 32-byte messages is processed in the encoder by a secret hash
|
||
algorithm which transforms the 32-byte message into a 60-bit value.
|
||
These 60 bits are then used by a second algorithm in order to determine
|
||
the 8-bit cut point coordinates for each line for the next 2.5 seconds.
|
||
No details about this second algorithm are known, but think of it just
|
||
as some kind of 60-bit pseudo random number generator (PRNG) were the
|
||
60-bit output from the secret hash function is used as a start value
|
||
(seed).
|
||
|
||
The decoder receives the 32-byte messages and other data together with
|
||
the TV signal, applies some error correction algorithms and passes all
|
||
32-byte packets to the smart card in the decoder's card slot. The smart
|
||
card implements the same secret hash function and answers with the same
|
||
60-bit value as the one which is used in the encoder. By using this
|
||
60-bit answer from the card, the decoder hardware can generate with the
|
||
same PRNG the same cut point sequence as the encoder and can so
|
||
reconstruct the original image by again exchanging the two line
|
||
fragments. The secret hash function is a cryptographically strong
|
||
system which is designed so that it is extremely difficult to guess the
|
||
algorithm of this function by looking at many pairs of 32-byte/60-bit
|
||
values.
|
||
|
||
Apart from being the source for the generation of the 60-bit PRNG seed,
|
||
the 32-byte messages from the broadcasting station contain card numbers
|
||
so that individual cards can be addressed and they contain commands
|
||
like activation, deactivation and pay-per-view account modification. In
|
||
addition, the 32-byte packets contain a digital signature (currently 4
|
||
bytes) that allows the card to test whether the 32-byte messages really
|
||
originate from the encoder and have not been generated by someone
|
||
analysing the card. Again, this digital signature like the hash
|
||
function has been designed so that it is difficult to find out how to
|
||
generate a correct signature by looking at enough examples. This
|
||
prevents choosen-text attacks, where someone tries to probe the secret
|
||
hash function with very carefully selected 32-byte messages and this
|
||
prevents hackers to generate new activation commands for the card.
|
||
|
||
In early 1993, someone managed to get access to the secret hash
|
||
functions of several stations which use Videocrypt (e.g., British Sky
|
||
Broadcasting, Adult Channel, JSTV, BOB, Red Hot TV). Most of these
|
||
systems used the same hash and signature algorithm and the only
|
||
difference between the stations was a 32-byte secret key table. It is
|
||
not known, how it was possible to get this information. Either someone
|
||
from the company who manufactured the cards (News Datacom Ltd.)
|
||
released this information or it was possible for someone to read out
|
||
the EEPROM contents of the card processor (very difficult, but
|
||
theoretically possible). With this knowledge it was then quite easily
|
||
possible for the original hackers to produce 'clone cards'. These are
|
||
simple PCBs with a cheap microcontroller (e.g. one of Microchip's PIC
|
||
family), which implements only the secret hash function and serial I/O
|
||
procedures in its EPROM and answers with the correct 60-bit values to
|
||
32-byte messages just as the real cards do. For several channels, clone
|
||
cards are still available, but BSkyB distributed new 09 series cards in
|
||
spring 1994 and switched on 1994-05-18 to a new secret hash ans
|
||
signature function. Consequently, all clone cards stopped to work.
|
||
|
||
The clone cards didn't implement any interpretation procedures for card
|
||
activation, deactivation and pay-per-view functions, so their software
|
||
is considerably simpler than the one in the real cards. This resulted
|
||
in some tiny differences between the reaction of the clone card
|
||
software and the reaction of the original card software on pathological
|
||
32-byte messages. These differences were used in counter measures
|
||
(commonly referred to as ECMs) against clone cards several times in
|
||
1993 and 1994 by BSkyS and News Datacom in order to deactivate clone
|
||
cards, but it was quite easy each time to find out these tiny bugs in
|
||
the clone card software and correct it.
|
||
|
||
There are two microprocessors in a typical Videocrypt decoder. An Intel
|
||
8052 microcontroler manages the communication between the smart card
|
||
and the rest of the system. As the software of this processor is not
|
||
read protected, it was also possible to reprogram this chip (by using
|
||
the EPROM version 8752BH) so that the hash algorithm is performed
|
||
inside the decoder. Then no external card is needed at all for the
|
||
channels for which the hash algorithm was implemented in the 8752. The
|
||
second processor is a Motorola 6805 variant and its internal ROM
|
||
contents can't be read out easily. The Motorola decodes the data that
|
||
comes with the TV signal, applies error correction algorithms to this
|
||
data, exchanges the 32-byte messages and 8-byte answers with the Intel
|
||
processor and controls the PRNG and the on-screen display hardware.
|
||
|
||
There are also Videocrypt II decoders available. These work almost like
|
||
the Videocrypt decoders and the only important difference is a new
|
||
software in the Intel and Motorola processor. Videocrypt II decoders
|
||
get their data from other invisible TV lines than Videocrypt, and it is
|
||
possible to broadcast a signal encrypted in a way that allows both
|
||
Videocrypt and Videocrypt II to decode it with different smart cards.
|
||
|
||
More detailed basic information about Videocrypt has been published in
|
||
the European patent EP 0 428 252 A2 ("A system for controlling access
|
||
to broadcast transmissions"). You can order a copy for little money
|
||
(about 10 DM) from the European Patent Office (Schottenweldgasse 29,
|
||
A-1072 Wien, Austria) if you are interested.
|
||
|
||
|
||
2 Security of the Videocrypt system
|
||
|
||
The system is very secure, because all secret parts that are essential
|
||
to a successful decryption are located in the smart card and if the
|
||
card's secret hash algorithm/key becomes known, it can easily be
|
||
replaced by just sending new cards to the subscribers. This card
|
||
exchange can also be used if details about the format of the commands
|
||
hidden in the 32-byte sequences sent to the card become known which
|
||
allows together with the knowledge of the signature algorithm to
|
||
generate new activation messages and to filter out deactivation
|
||
messages.
|
||
|
||
There are however at least two obvious security flaws of the system
|
||
which can't be removed by new smart card generations:
|
||
|
||
- The dialog between the card and the decoder is the same synchronously
|
||
for all Videocrypt decoders switched to this channel. I.e., the decoder
|
||
doesn't add any card specific or decoder specific information to the
|
||
traffic. This makes it possible to use one card for several decoders.
|
||
E.g. it is possible to record the 32-byte messages broadcasted by
|
||
the station during an evening with a PC, then send these messages to
|
||
someone else with an original card who asks his card for the 60-bit
|
||
answers to all the recorded messages. If this person then sends
|
||
these 60-bit answers back, then you can use this data in order
|
||
to descramble the VCR recorded program of this evening (delayed data
|
||
transfer). However, decoding VHS recorded encrypted signals produces
|
||
minor color distortions and a few VCRs don't preserve the Videocrypt
|
||
data stream in the first invisible lines that accompanies the TV
|
||
signal. It is also possible to distribute the 60-bit answers from
|
||
one card in real-time with cables to many decoders in a house or
|
||
with radio signals to many decoders in a larger region.
|
||
|
||
- The simple cut-and-exchange encryption method and the fact that two
|
||
consecutive lines in an image are almost always nearly identical
|
||
makes it possible to try all 256 possible cut points and to select
|
||
the one which causes both lines to fit together best. This method
|
||
has alreday been implemented on fast PC's with framegrabbers which
|
||
load the image into the memory and display it corrected on the computer
|
||
screen (many seconds per frame), on parallel supercomputers which
|
||
allow almost real-time decryption and with special hardware that
|
||
achieves real-time decryption. Howevery, with this decoding method,
|
||
there are severe image quality losses and many additional problems
|
||
which together with the high hardware costs required (much higher
|
||
than a regular subscription) don't make this approach very practical
|
||
for every day usage.
|
||
|
||
Both these security gaps in the videocrypt systems don't allow
|
||
comfortable and easy high quality decryption like using a card, but the
|
||
described methods have already been successfully used by a few
|
||
technically skilled peoples for watching encrypted program.
|
||
|
||
|
||
3 ISO card protocol
|
||
|
||
The card and the protocol used to cummunicate with it conform exactly
|
||
to the international standard ISO 7816. The options used from this
|
||
standard are: T=0 asynchronous halfduplex character transmission
|
||
protocol, active low reset and inverse convention. Only a few basic
|
||
principles of the ISO protocol will be explained here. For much more
|
||
detailed information, please read the ISO standard which you can order
|
||
from your national standards body (e.g. DIN, ANSI, AFNOR, BSI, DS,
|
||
etc.). There are three parts of the standard: ISO 7816-1 describes
|
||
physical characteristics of the card and quality tests a card has to
|
||
survive, ISO 7816-2 describes the location and meaning of the contacts
|
||
and ISO 7816-3 (most important) describes the electrical
|
||
characteristics, the answer-to-reset message and the protocol.
|
||
|
||
The data format is an asynchronous 9600 bit/s serial format similar to
|
||
that used on RS-232 lines with 8 data bits, 1 parity bit and two stop
|
||
bits. The parity is even (but if inverse bit meaning convention is
|
||
used, a RS-232 interface has to be programmed for odd parity in order
|
||
to produce the correct bit). There is also an error detection and
|
||
character repetition mechanism in the protocol which is not supported
|
||
by RS-232 interfaces: If the receiving device (card or decoder) detects
|
||
a parity error, it sends an impulse during the stop bit time. This will
|
||
tell the sender to retransmit one byte.
|
||
|
||
After a reset impulse to the card, the card answers with an
|
||
answer-to-reset message with some information about the requirements of
|
||
the card. If the first byte is 3fh, then this means that in order to
|
||
read the bytes with a RS-232 interface, you'll have to invert and
|
||
reverse all bits. A typical answer-to-reset looks e.g. like the
|
||
following one:
|
||
|
||
3f fa 11 25 05 00 01 b0 02 00 00 4d 59 00 81 80
|
||
| | | | | | 'historic characters' with|
|
||
| | | | | | information about chip and|
|
||
| | | | | | software version, etc. |
|
||
| | | | |
|
||
| | | | +- low nibble: protocol type T=0,
|
||
| | | | high nibble: end of ISO part
|
||
| | | |
|
||
| | | +- requests 5 additional stop bits
|
||
| | |
|
||
| | +- encodes programming voltage and max. programming
|
||
| | current (here: 5V, 50mA)
|
||
| |
|
||
| +- clock freq.: 11h=3.5 MHz, 31h=7 MHz
|
||
|
|
||
+- the 0ah low nibble means: 10 'historic characters' which
|
||
are not defined in the ISO standard are appended to
|
||
the reset answer
|
||
|
||
The answer-to-reset message has a variable length format. Some bits
|
||
specify whether certain bytes are present or not. If the lowest bit in
|
||
the high nibble of the second byte is 1, then the above shown third
|
||
byte is present and determines the relation between the bit rate and
|
||
the clock frequency after the reset answer. E.g., 11h means that 372
|
||
clock cycles are one bit duration (default), i.e. with a clock
|
||
frequency of 3.5712 Mhz, the bit frequency is 9600 Hz. In the
|
||
Videocrypt system, the bit rate is always 9600 bits/s, but a value of
|
||
31h (= factor 744) in the third byte requests a doubled clock frequency
|
||
(~7MHz) from the decoder. Other values are not supported by the
|
||
Videocrypt decoder.
|
||
|
||
The Videocrypt decoder supports several programming voltages (5 V, 12.5
|
||
V, 15 V and 21 V, max. 50 mA current) and different numbers of stop
|
||
bits (>= 5) sent to the card. All these parameters can be selected in
|
||
the answer-to-reset. Of the 'historic characters' part, the decoder
|
||
only verifies that it is at least 7 characters long and that the values
|
||
4dh und 59h are at the positions as in the example, otherwise the card
|
||
is rejected. No more details about the information in the historic
|
||
characters part of a Videocrypt card is currently known. For the
|
||
detailed format of the answer-to-reset message, please consult ISO
|
||
7816-3.
|
||
|
||
The T=0 protocol is a half duplex master slave protocol. The decoder
|
||
can send commands to the card followed by a data transmission either to
|
||
or from the card. The card can do some limited flow control and can
|
||
request or deactivate the programming voltage VPP selected in the
|
||
answer-to-reset using "procedure bytes". If the decoder initiates a
|
||
command, it sends five header bytes to the card, e.g.
|
||
|
||
53 78 00 00 08
|
||
|
||
The first byte (CLA) is the command class code and is always 53h in the
|
||
Videocrypt system. The second byte (INS) is the instruction code. Its
|
||
lowest bit is always 0 and instruction codes have never a 6 or 9 high
|
||
nibble (you'll see below, why). The following 2 bytes (P1 and P2) are a
|
||
reference (e.g. an address) completing the instruction code and a
|
||
Videocrypt decoder sets them always to 00 00. The final byte (P3) codes
|
||
the number of data bytes which are to be transmitted during the
|
||
command. P3=0 has a special meaning: In data transfers from the card,
|
||
it indicates 256 data bytes, in data transfers from the decoder, it
|
||
indicates 0 bytes. The direction of the data transfer is determined by
|
||
CLA and INS and must be known in advance by both the card and the
|
||
decoder.
|
||
|
||
After transmission of such a 5-byte header, the decoder waits for a
|
||
'procedure byte' from the card.
|
||
|
||
The following procedure bytes are possible:
|
||
|
||
60h Please wait, I'll send another procedure byte soon,
|
||
don't timeout.
|
||
|
||
INS Now let's transfer all (remaining) data bytes, I don't
|
||
need programming voltage.
|
||
|
||
INS+1 Now let's transfer all (remaining) data bytes and please
|
||
activate VPP.
|
||
|
||
INS xor ffh Now let's transfer another single data byte,
|
||
I don't need programming voltage.
|
||
|
||
(INS+1) xor ffh Now let's transfer another single data byte, and please
|
||
activate VPP.
|
||
|
||
6Xh or 9Xh This byte SW1 indicates an end of the data transfer
|
||
and requests to deactivate VPP. A second status byte SW2
|
||
follows from the card. SW1 SW2 = 90 00 indicates a
|
||
normal termination, other values report e.g. an error.
|
||
|
||
After each data transfer, the decoder waits for another procedure byte.
|
||
E.g., a typical decoder<->card dialog looks like this (command 78h
|
||
requests the 60-bit answer as 8 bytes from the card):
|
||
|
||
decoder sends header
|
||
53 78 00 00 08
|
||
card sends procedure byte (all at once, no VPP)
|
||
78
|
||
card sends P3 data bytes
|
||
80 52 02 79 f5 39 7c 0e
|
||
card closes with SW1 and SW2
|
||
90 00
|
||
|
||
|
||
4 Videocrypt protocol
|
||
|
||
The newer Videocrypt smart cards don't require any programming voltage
|
||
(the VPP pin isn't even connected). Although, the ISO standard requires
|
||
only 2 stop bits after each transfered byte, Videocrypt decoders seem
|
||
to require more than 5 stop bits. As PC serial ports don't support more
|
||
than 2 stop bits directly, a card emulator software has to wait for
|
||
about 0.5-1.5 ms after each byte. Cards can announce in the
|
||
answer-to-reset message, how many stop bits they require and Videocrypt
|
||
cards also do require more than 2 stop bits.
|
||
|
||
A videocrypt decoder knows the following 10 commands (all with CLA=53h
|
||
and P1=P2=00h):
|
||
|
||
INS length (P3) direction purpose
|
||
---------------------------------------------------------------------
|
||
70h 6 from card serial number, etc.
|
||
72h 16 to card message from previous card
|
||
74h 32 to card message from station
|
||
76h 1 to card authorize button pressed
|
||
78h 8 from card 60-bit answer
|
||
7ah 25 from card onscreen message
|
||
7ch 16 from card message to next card
|
||
7eh 64 from card ??? \
|
||
80h 1 to card ??? > perhaps Fiat-Shamir
|
||
82h 64 from card ??? / authentication?
|
||
|
||
The following things are known about the data bytes of these commands:
|
||
|
||
70h:
|
||
|
||
In BSkyB cards, the 70h data contains the card issue number (e.g. 07 or
|
||
09) in the low nibble of the first byte. The high nibble of the first
|
||
byte seems to be always 2. The next 4 bytes form an 32-bit bigendian
|
||
integer value which corresponds to the decimal card number without the
|
||
final digit of the card number (which is perhaps a check digit,
|
||
algorithm unknown). The meaning of the final byte is unknown.
|
||
|
||
72h and 7ch:
|
||
|
||
Several times per second, the decoder requests with 7ch 16 bytes from
|
||
the card. If a card is removed and a new card is inserted in the
|
||
decoder without switching off the power of the decoder, then shortly
|
||
after the card reset, the decoder sends the latest 7ch data bytes from
|
||
the previous card in a 72h message to the new card. In this way, 16
|
||
bytes information (e.g. the status of a pay-per-view account or a list
|
||
of activated channels?) can be transfered from one card to the next.
|
||
|
||
74h and 78h:
|
||
|
||
The 74h command transfers the 32-byte messages from the broadcasting
|
||
station to the card. If the third bit (value 8) in the first byte is
|
||
set, then the decoder will ask with a 78h command for the 60-bit
|
||
answer. This happens about every 5th 74h packet every 2.5 seconds. The
|
||
high nibble of the final byte in the 78h data is ignored by the decoder
|
||
(only 60 bits are needed). The high nibble of the first 74h byte seems
|
||
to have the value eh or fh in normal encrypted operation and ch or dh
|
||
in the 'soft scrambled' mode where the decoder can descramble the image
|
||
even without any card.
|
||
|
||
The following information is valid for the 07 and 09 BSkyB card and need not
|
||
necessarily be true for future smart cards, because these data bytes
|
||
don't seem to be interpreted in the decoder and so their meaning can be
|
||
exchanged. A typical BSkyB 74h packet for the 09 series card looks like
|
||
this:
|
||
|
||
e843 0a888261 0c 29e403f6 20202020202020202020202020202020 fb54ac02 51
|
||
|
||
The second byte indicates the current date and counts the months since
|
||
January 1989. In the 07 card, this month code selects one of several
|
||
32-byte secret key tables that are used by the hash function. When the
|
||
switch from the 07 hash algorithm to the new 09 algorithm happened on
|
||
1994-05-18, this value jumped from 40h (1994-05) to 43h (1994-08) which
|
||
might indicate that the activation of the 09 algorithm was originally
|
||
planned for August. In the 07 card, this value was only interpreted to
|
||
find an offset into a table with various 32-byte secret keys.
|
||
|
||
The third byte seems to be a random number. This byte together with the
|
||
month code is used to generate with a quite simple algorithm four XOR
|
||
bytes which are necessary to decode the command byte and the card
|
||
number prefix (described below). If you XOR these four bytes with bytes
|
||
8 to 11 and if you the XOR only the first of the four bytes with byte
|
||
4, then you have decrypted the card number and the command code.
|
||
|
||
The fourth byte is an encrypted command code. Some decrypted known
|
||
values are:
|
||
|
||
0x00 Deactivate whole card (message: 'PLEASE CALL 0506 484777')
|
||
0x01 Deactivate Sky Movies (message: 'THIS CHANNEL IS BLOCKED')
|
||
0x02 Deactivate Movie Channel
|
||
0x03 Deactivate Sky Movies Gold
|
||
0x06 Deactivate Sky Sports
|
||
0x08 Deactivate TV Asia
|
||
0x0c Deactivate Multichannels
|
||
0x20 Activate whole card (remove 'PLEASE CALL 0506 484 777')
|
||
0x21 Activate Sky Movies (remove 'THIS CHANNEL IS BLOCKED')
|
||
0x22 Activate Movie Channel
|
||
...
|
||
0x2c Activate Multichannels
|
||
0x40 Pay-per-view account management command
|
||
0x80 \
|
||
0x81 \ perhaps 09 card ECM
|
||
0xf0 / commands
|
||
0xf1 /
|
||
|
||
Packets with incorrect command bytes and correct signatures can
|
||
irreversibly kill a card (it doesn't even answer the reset).
|
||
|
||
The fifth and sixth byte seem to be parameters for pay-per-view account
|
||
management (program number and number of tokens) and don't seem to have
|
||
a meaning for enabling and disabling commands.
|
||
|
||
The lower 7 bits of the seventh byte contain a channel ID.
|
||
|
||
A card number is represented by a 5 byte card address consisting of a 4
|
||
byte prefix and a 1 byte suffix. The five bytes for a card are
|
||
identical to the first 5 bytes of the 70h answer, only the high nibble
|
||
of the first address byte seems to have a different purpose (unknown).
|
||
Up to 16 cards with the same card address prefix can be addressed with
|
||
one single 32-byte 74h message. The bytes 8-11 might contain the common
|
||
prefix to the addressed cards and the bytes 12-27 the various suffixes.
|
||
If there are less than 16 different cards to be addressed, then the
|
||
same suffix byte is repeated several times in order to fill the space.
|
||
The 4-byte prefix is encrypted like the command byte by XORing it with
|
||
the four bytes generated using the bytes 2 and 3.
|
||
|
||
The 4 bytes 28-31 contain the digital signature which is simply an
|
||
intermediate result of the iterations of the hash algorithm. If the
|
||
checksum, the digital signature, or some of the values in the first 7
|
||
bytes of a 74h command aren't correct, then the 78h answer will only
|
||
contain 8 00 bytes or in some cases 01 00 00 00 00 00 00 00. The final
|
||
byte 32 is a simple checksum that makes the sum of all 32 bytes a
|
||
multiple of 256.
|
||
|
||
The 07 card (and also cards used by Sky New Zealand) have an
|
||
interesting security hole: The card sends to the decoder as many data
|
||
bytes as specified in P3. By sending a higher length value in the
|
||
command header to the card, one can get up to 256 data bytes back which
|
||
seem to be values from the card's RAM that allow some insight into the
|
||
internal data structures of the card software.
|
||
|
||
76h:
|
||
|
||
If the authorize button on the decoder is pressed for a few seconds,
|
||
then the decoder will send a single 76h message with a 00 data byte to
|
||
the card.
|
||
|
||
7ah:
|
||
|
||
This command requests from the card an ASCII text which is then
|
||
displayed on the TV screen. The display field is 12 characters wide,
|
||
one or two lines high and no lowercase letters are supported. The lower
|
||
5 bits in the first byte indicate, how long the text is which is to be
|
||
displayed: 0 for no display, 12 for a single line and 24 for 2 lines.
|
||
The highest 3 bits of the first byte seem to be some kind of display
|
||
priority. The number there (0-3) must be high enough if standard
|
||
decoder messages have to be suppressed. The remaining 24 bytes contain
|
||
the ASCII test.
|
||
|
||
The meaning of the other commands is unknown, some of them are never
|
||
used currently. Perhaps these commands are used for the Fiat-Shamir
|
||
identification exchange described in the patent. Some cards understand
|
||
also additional instruction codes which can't be issued by a normal
|
||
decoder. E.g. a BSkyB 09 card understands also 12h, 86h, 88h, 8ah and
|
||
8ch. These commands are perhaps used in order to test or configurate
|
||
the card at the factory, etc.
|
||
|
||
Please contact me if you find out anything new. My e-mail address is
|
||
mskuhn@cip.informatik.uni-erlangen.de.
|
||
|
||
|
||
5 VCL File Format
|
||
|
||
The Videocrypt Card Logfile format (VCL) is used by some peoples for
|
||
performing the delayed data transfer procedure described in section 2.
|
||
Person A with a valid card can record the dialog between the decoder
|
||
and the card for a certain program P and transmit this information as a
|
||
VCL file to person B who has no card and has recorded with a VCR only
|
||
the encrypted signal of program P. Person B now connects the Videocrypt
|
||
decoder between the VCR and the TV set and connects the card slot of
|
||
the decoder to a PC. Using the information in the VCL file, B's
|
||
computer can now also decrypt program P. This is of course only
|
||
possible for the few hours which are covered by the information in the
|
||
VCL file.
|
||
|
||
Not all of the information exchanged between the card and the decoder
|
||
is necessary for descrambling the TV signal. The VCL format uses this
|
||
fact in order to save a lot of storage space. Only 12 bytes of high
|
||
entropy (that means: almost uncompressable) are stored every 2.5
|
||
seconds. So a VCL file of a 1 hour program is only about 17 kbytes
|
||
large. In addition, VCL files don't contain any information about the
|
||
card owner (especially not the card serial number), which appears in
|
||
normal full log files. (The only potential security hole is the
|
||
remaining nibble in the 78h data, consequently it should be cleared in
|
||
order to avoid card specific information to leak into the VCL file.)
|
||
|
||
VCL files have a very simple binary format consisting of a 128 byte
|
||
header and arbitrarily many 12 byte records. At the end, VCL files may
|
||
be padded with zero bytes to a multiple of the operating system's disk
|
||
sector size, so that no RAM contents can leak in there out of an
|
||
unsecure system like MS-DOS. Don't forget to use a binary mode if you
|
||
transfer VCL files or their contents will be rendered unusable.
|
||
|
||
The 128 byte header has the following format:
|
||
|
||
byte number purpose
|
||
|
||
0 - 3 ASCII String 'VCL1' which identifies the file
|
||
type and version of the format.
|
||
4 - 7 The number of 12-byte records stored in this
|
||
file encoded as a bigendian (most significant
|
||
byte first) 32-bit unsigned integer value.
|
||
8 - 23 Date and time when the recording started.
|
||
Format: yyyymmddThhmmssZ, where yyyymmdd are
|
||
year, month and day (e.g. '19940618'), hhmmss
|
||
are hour, minute and second (e.g. '235959'),
|
||
T ist just the ASCII letter T, and Z is
|
||
the ASCII letter Z if the time is UTC or
|
||
a zero byte, if the time is local time. The
|
||
digits are ASCII characters.
|
||
24 - 55 Name of the satellite or cable system from
|
||
which the recording was done. This is a zero
|
||
terminated ASCII string with only characters
|
||
between 20h and 7eh. As many zero bytes are
|
||
appended as necessary for filling up the 32
|
||
bytes. The same format is also used for the next
|
||
two text fields. Example: 'Astra'.
|
||
56 - 63 Name/number of the transponder from which
|
||
the recording was done. Example: '08' for
|
||
Sky One on Astra.
|
||
64 -127 Description of what has been recorded.
|
||
Example: 'Star Trek: TNG, episode 123'
|
||
|
||
After the first 128 bytes follow as many 12 byte records as announced
|
||
in bytes 4-7. Each record represents a 74h/78h Videocrypt protocol pair
|
||
and constists of two fields: The first 4 bytes are the final 4 bytes of
|
||
the 74h data part, the remaining 8 bytes are the data part of the
|
||
corresponding 78h command. Four bytes of each 74h packet are enough to
|
||
allow a card emulator to quickly and reliably synchronize with the
|
||
queries of the decoder. The final four bytes of the 74h commands have
|
||
been selected because of their high entropy (signature and checksum).
|
||
|