For all its digital complexity, the European VideoCrypt system still depends on a 9600 Baud data link to a smart card. The smart card is an eight bit processor based on a 6805. It is not fast enough to use calculation intensive algorithms such as RSA (Rivest Shamir Adelmann). As a result the algorithms used have been register based hashing algorithms. These hashing algorithms are designed to be fast and efficient.
In the European VideoCrypt system, two packet types are associated with the decryption process; the 74h packet and the 78h packet. It is not yet known (in Europe) what packet format and structure the DSS system uses. Since the smart card interface conforms to the ISO-7816 specification, monitoring of the data would indicate the packet types in use.
In terms of economy, it is possible that News Datacom used an essentially similar packet structure though the actual algorithms may be slightly different.
Some of the differences will be in the Pay Per View routines. In the European VideoCrypt system, the main PPV routines were incorporated into the card-decoder interface microcontroller. This chip also held the PPV token reservoir. It would be strange if such a mistake was repeated in the DSS system.
In the DSS IRD, the microcontroller that controls the card - decoder interface is a custom microcontroller. It is also protected. With the European VideoCrypt system, a major mistake was made and this microcontroller was not protected. Hackers were able to dump out the ROM from this controller and were able to attack the system. They rewrote the code and loaded into an EPROM version of the microcontroller. This modified code looked for the card's identity number in a switch off packet. This hack, known as the KENtucky Fried Chip, prevented Sky from switching off a smart card.
Of course the card - decoder microcontroller would have been the first chip in the DSS IRD to have been reverse engineered. The reverse engineering of a customized microcontroller is not, in most cases, as difficult as a smart card. In mass produced IRDs and decoders, the microcontrollers used are typically ROM versions of commonly available microcontrollers. Some of them have simple back doors.
The 74h packet is the workhorse of the VideoCrypt system. This message packet carries all of the card turn on and turn off codes. It is also used as the input data for the hashing algorithm that generates the decryption key.
The data in this packet has a 27 - 4 - 1 structure. The first twenty seven bytes contain the decoder flags, the card addressing instructions, the channel identifier and the card addresses affected by this packet. The next four bytes are a hash algorithm checksum.
When the packet is processed by the hash algorithm, part of the results in stages 28, 29, 30 and 31 should equal the bytes in these checksum bytes. The card will reject packets that do not have a valid checksum. The function of the checksum is to prevent a chosen plaintext attack on the hash algorithm or a third party authorisation of a smart card.
The final byte is a packet checksum. The value of this byte is that required to bring the sum of the bytes in the packet to a multiple of 256.
Byte 0 in this packet carries the decoder flags. It effectively tells the decoder how the packet is to be handled. The high nybble identifies the type of scrambling in use. A value of Cxh indicates that the channel is not scrambled. A value of Exh or Fxh indicates that the channel is hard scrambled. The Dxh value may indicate a free access mode of scrambling. The value x8h as the low nybble indicates that the packet is to be used to generate a new decryption key. The value x0h indicates that the packet is an information packet and is not to be used to generate a new key.
Another important element is the packet type byte. This byte identifies the packet as being a switch-on, switch-off or ECM packet. The ECM packet is the packet that carries the Nanocommands. Basically speaking, the area of the packet that would normally be occupied by card identity numbers carry a routine that is loaded into the smart card. This is the back door.
The 78h packet is the eight byte decryption key generated by the hash algorithm in the smart card. This key is passed to the Pseudo Random Number Generator in the Custom Logic IC in the European VideoCrypt decoder. Only 60 Bits of this result is used to seed the PRNG.
There are four requirements for the Vampire hack. The first is a working implementation of the hash algorithm. This is necessary as the state of the answer bytes has to be tracked through the whole process. The hash implementation is also required to generate a valid checksum for the packet.
The second requirement is a set of current Phoenix codes or alternatively the algorithm for generating these codes. These codes will be Exored with the packet data before the checksum is generated. Since the KENtucky Fried Chip, News Datacom have had to encrypt the information in the 74h packets. In order for the Vampire packets to be accepted and processed by the smart card, they have to be properly encrypted.
The third requirement is a working knowledge of the nanocommands. The basic commands in the Vampire hack are the 09h address loader, the 30h data processor and the 03h break. It is necessary to know how many hash iterations are effected by each nanocommand. This is where much of the research work will have to be carried out with the DSS. It would be extremely lucky for the hackers if News Datacom used the same nanocommands in the DSS card.
However, if they considered that the card and the hashing algorithm could not be popped, then they may well have used similar nanocommands. The Nanocommands in the 09 Sky card seem to be based on 6805 commands.
The fourth requirement is some sort of recovery routine. This routine will exhaustively search for the data byte used in the 30h command. This is perhaps the most intensive part of the algorithm and some hackers decided to leave this stage until after the results are obtained from the card.
Basically this stage involves setting the address bytes that follow the 09h command.
This is where the Nanocommand Decrypt Key algorithm is applied to the packet data. It EXORs the output of the encrypt algorithm with the nanocommands and other data.
The packet presented to the card has to have a valid checksum otherwise the card will reject it. Again the working implementation of the hash algorithm is required. In many respects this process is similar to the original Phoenix program.
The Vampire packet is sent to the card. The circuitry used for this stage is the same as that used for the Phoenix hack.
The answer packet from the card would be recorded in a file along with the address of the data, the nanocommands used and the state of the answer bytes just prior to the execution of the nanocommands.
Theoretically this is a simple stage. In practice it is complex. The state of the answer bytes prior to the execution of the nanocommands is known. The process used here is an exhaustive search. The 30h and 03h iterations would be executed exhaustively with all values from 00h to FFh being tried as the input in the 30h loop. The potential for errors exists but it is the simplest way, short of reverse-engineering the card, of obtaining the contents of the card memory.
On paper these stages look simple. In reality they are complex. The main problem with the European situation was working out how the recovered data mapped back to standard 6805 commands. Eventually, the op-codes were established and the routines began to make sense. The hackers now have a fully dissembled dump of the ROM and EEPROM of the Sky 09 smart card.
It is also probable that the DSS hackers have used the Sky 09 data and knowledge to attack the DSS smart card. The problem for the DSS hackers is knowing the extent and power of the Nanocommands in the DSS card. DSS may have a trick or two in its cards.
Copyright (c) 1995 Hack Watch News