It is illegal to view European PAY-TV channels within Europe Without a subscription! The information and freeware on this site is meant for educational purposes only! The webmaster, designers and owner of this domain can and will not be held responsible for any damage done by illegal use of the information that could be provided on this site. By entering this site you agree to these terms!

THE MOSC COMPENDIUM- by Kuband
 1.0 Introduction


a) What's a MOSC?


MOSC stands for modified original smart card. This is an experimenter's name for a hacked smart card that was originally supplied by the PayTV company. In more recent times it seems to have been used as a generic term for almost any sort of work with PayTV decryption.

b) What's a Compendium?

A compilation of information on related topics.

That is what this document is, a collection of information for those who wish to move on from the 'newbie' stage, as addressed in my guide for newcomers to the hobby. In this document we will look more closely at programmers, some advanced card concepts and analyse some script contents. A reference for this information is, once again, "Activate" V11 courtesy of 007.4.

c) Why do I write this stuff?
Some days I wonder myself. The realities are that for a newcomer to the hobby, getting information can be like looking for a needle in a haystack when no-one will tell you where the haystack actually is. I am no expert and any experienced MOSC hobbyist will find much of this document trivial. A newcomer should learn something without being overwhelmed with complex information.
There is a certain amount of secrecy in this hobby. Some of it is quite irrational, some of it is probably justified. There is also a general (but not universal) conspiracy of non-cooperation motivated by the idea that goes something like ““I had to hunt this down, so you must too””. Fortunately for us, people like 007.4 and those that wrote and released the software and hardware designs around the place did not suffer from such restrictive thinking. This is not a hobby for the ordinary PayTV subscriber. A certain level of ability is needed along with cooperation from others.

2.0 Hardware Notes

2.1 Cards and Programmers

So far I have treated programmers as a ‘black box’, just add power, a card and a PC and away you go. Let’s look a bit closer at what they do. To do this, the easiest thing to do is look at what a smart-card requires to be able to work. The interface to the smart card is defined by an ISO standard. There are 5 connections to a smart card. Yes, I know there are 8 pads (or more on some cards) but only 5 connections matter. The connections are +5V, Ground, Clock, I/O and Reset. Lets look at each of these:

+5v

This is the power supply to the card. It should not deviate too far from this but my experience is that it is tolerant of variations of a few hundred millivolts without noticeable effect. The card current drain is only a few milli-amps.

0v (Ground)

Fairly self-explanatory. This is usually the largest pad in the card connector.
The programmer must be capable of supplying power to the card. Power can be derived from the decoder if the programmer is on a pcb with connection pads and capable of being inserted into a card slot (e.g. a season board). This is not a particularly reliable way of driving the smart-card electronics as sometimes the other circuitry on the card may exceed the current capability of the decoder card-slot. The alternative is to supply power to the programmer board from an external source. The most po****r (and best) method is to have a 5 volt regulator on the programmer board to supply the electronics. The board may then be powered by a supply of between about 7 and 20 volts.
The current drain of my (home-brew) programmer is around 70 mA and it has extra circuitry to drive led indicators etc. For some reason it has been suggested that a current capability of 500 mA is needed for some programmers. This seems excessive and I can only assume what is really need is a ‘stiff’ power supply that does not sag at the usual current drain of the programmer. No programmer should draw anything near to 500 mA!
Clock
The smart card is almost a microcomputer is its own right and needs a clock source in order to function. This can really be any frequency within the operating range of the card circuitry. There are 2 common frequencies being 3.58 and 6 MHz. Most Australian decoder smart-cards actually operate at around 6 Mhz and I suspect the 3.58 Mhz frequency was originally selected to keep the cost of programmers lower as this frequency crystal is a cheaply available type, being the colour sub-carrier frequency of the U.S. N.T.S.C. colour TV system.
This frequency sets the baud rate for card communications, this being a sub-multiple of the clock frequency. For 6 MHz the baud rate is 9600 and is the preferred option. Your programming software MUST be set to match the clock frequency.
The clock signal is commonly derived from an on-board oscillator. This can be an oscillator module or constructed using a crystal and I.C. combination. Some boards offer optional 3.58 / 6 Mhz selection though this is really unnecessary as a 6 Mhz clock will accommodate all current software. The oscillator produces a 5v p-p square wave signal for application to the card clock terminal. If the board is a season type board also to be used for logging, the oscillator signal may be able to be disconnected to allow the decoder to supply the signal instead.
I/O
The I/O line of the smart card is bi-directional. The CAM initiates a request on this line and the card responds. Our programming software just takes the place of the CAM. The signal is a conventional serial signal comprising a start bit, eight data bits and a stop bit. Low = 0v, High = 5v.
The i/o line needs to be controllable by the programmer or by the card (or CAM) depending on who is ‘talking’ at the time. More about how this is done later.
Reset
This is the hardware reset line, active low. Sometimes called the Clear line.
The reset line is active low. In other words it is normally at 5 volts for card operation and will reset the card electronics when pulled low. Some software requires control over this line and again, if the board is a season type being used as an emulator, the software usually needs to monitor the state of the reset from the decoder (e.g. CardEmu, Voyager)

2.2 Programmers
OK, so now you know what the card needs. Lets look at a common programmer, the Minimax. There is a circuit diagram in the files with this document. The Minimax is a bare bones programmer only. This device is probably about as simple as they come. It has 3 ICs, a MAX232, a 74HC04 and a 78L05 regulator.
The 78L05 provides 5 volts to the other devices on the board. It can be powered from a 9 volt battery or a power supply such as a plug pack.
The 74HC04 is 6 inverters on a chip, of which only 3 are used. One is used to form an oscillator and another buffers and conditions the output to supply the clock signal to the smart card. In the circuit attached, a 3.58 Mhz crystal is used. This could be substituted with a 6 Mhz if desired. The third inverter is an optional inclusion (by jumpers) in the Reset (Clr) line to the card. This is to make the Minimax compatible with another programmer called the Phoenix, which uses the opposite polarity of signal for the Reset. This requirement is determined by the software and most modern software versions have an option to invert the Reset signal so it is really unnecessary these days.
The MAX232 is an RS232 line driver/receiver. It has 2 inputs and 2 outputs for RS232 level signals. RS232 signals use –12 volts for one state and +12 volts for the other. These signals come from the PC and are obviously incompatible with the 0 volts and +5 volts used by the card. The MAX232 translates the +/- 12 V signal to a 0/5 V signal and vice versa. In order to supply +/- 12 volts, the chip has on-board DC-DC converters to generate those higher voltages. The electrolytic capacitors (usually 1 or 2.2 mF) associated with the device are part of that power supply circuit.
The 2 signals from the PC to the programmer are ‘data-in’ and ‘reset (clr)’. Likewise the 2 outputs from the programmer are ‘data-out’ and card switch. Card switch looks at a switch built into the smart-card socket and is used to tell the software that a card is present in the socket. Some programmers have an option to invert this signal to suit different software or card sockets. Note also that the ‘season interface’ type device actually needs to use this line to monitor the card reset line rather than the switch. This is important as most of the emulators now in use monitor this line as a trigger to initiate communications with the CAM.
So, we have a ‘data-in’ line and a ‘data-out’ but only one data pin on the smart-card. This is where the diode, BAT41, comes into the picture. This is no ordinary diode and should only be substituted by one of similar characteristics, in this case a Schottky diode. Schottky diodes are characterised by 3 main features being low junction capacitance, rapid switching capability and low forward voltage drop. The first 2 are not an issue here. It’s the low forward voltage drop that is needed.
Here’s what happens. Assume the data-in and data-out on the 5 volt side of the MAX232 are both normally high (+5v). The data-in line is set high by the programmer software. The data-out line is normally high when there is no activity on the smart-card i/o line. Now, suppose that the software sends a script to the card. The data-in line will be switching low with the data. The cathode of the BAT41 is connected to this line and is pulled low by the data signal. As the anode is connected to the smartcard i/o line, the BAT41 is now forward biased and pulls the i/o line low also, following the data signal. Here’s where the low forward voltage matters. If it was a normal diode, the i/o line would be pulled down to about 0.7 volts. This is not sufficiently low enough for either the smart-card or the MAX232 data-out line to recognise as a definite logic 0 level. With the BAT41, the voltage is around 0.1 volts which is recognised by the devices as a logic 0 level.
Now, what happens when it’s the card’s turn to ‘speak’. The i/o line of the card is connected directly to the MAX232 data-out line so the card’s answer is sent to the PC. In this instance, the data-in line is set back at its normal 5 volts by the software and when the i/o line goes low the BAT41 is reverse biased, (ie. off) so the data-in line has no influence over the i/o line.
Note that any data coming in on the data-in line will be echoed back out on the data-out line. This gives us a simple check of the full signal path by using a terminal program and seeing if loop-back of the signal occurs.
Other smart-card programmers use a different technique (and one I prefer). The diode is replaced by the output of one of the gates in a 7407 I.C. The 7407 is an open collector device, meaning that if the output of that gate is set high, it can be pulled low by external influences (ie. the smartcard) without risk of excessive gate output current (as there is none). When set low, the open collector transistor can pull the i/o line to less than 0.1 volts. It is this technique that I used in the ‘seasoned Pace’ box modification by utilising an unused inverter on the board and a transistor to form the open-collector output connected to the i/o line in the box.
With the exception of some very complex processor based programmers now around, all others use essentially the principles outlined above. Some offer a number of configuration options via jumpers or switches but all must be able to create the operating conditions I have described.
The ‘Season’ Programmer
Stupid name. It actually is a leftover from the early days of card controlled PayTV when a card could give you a season of programs (eg. 13 episodes of Star Trek.) These boards were designed and used to hack the season card system so became known as season boards. They are a combination logger and programmer. The ‘passive’ version cannot normally program cards (but there is a way, see other articles). It is because the data line is connected to the smart card slot when the board is plugged into a decoder that we can use these devices with emulators. It is a convenient way for the emulator to see the data i/o from the CAM in the decoder.
3.0 Smart-Card Theory Re-visited

Lets look again at some of the rules associated with smart cards. Once again, Activate is a useful reference for some more detail but it is starting to show its age. Recent terminologies such as HMK, PMK, PK etc are not referenced much. This is understandable because as the hobby evolves and different techniques emerge, different terminology is adopted. Just writing Activate must have been quite a task, not to mention constantly updating it! We all owe 007.4 our thanks for the work involved.
1. Hex Master Key (HMK)
To be fully functional, all cards need to have a Hex Master Key. This10 byte number forms a key part of the decryption algorithm. It can now be replaced using cloning techniques. Finding this number involves using a slightly fussy process using Cardwizard. If the card is not a V1.2 or a 1.6, as far as I am aware it cannot be read from the card.
For our purposes, its main use is to decrypt master-keys to produce new plain master-keys. Knowing the HMK associated with a specific subscribed card is a desirable thing as it permits emulators, wafer-cards and certain decryption software to provide an update path for master-keys etc and hence immunity from being killed as long as the original card remains subscribed.
2. Master Keys (MK)
For our purposes, the main use of a master key is to decrypt it to a plain master key. It is also used by the providers to change the Provider ID and plain master-key on cards. It is not stored on the card, but the decrypted version can be extracted from certain buffers on the card. This is what programs such as Key-Decrypt do.
Master keys can be obtained by logging or by ‘reverse engineering’ it with suitable software. If you have an expired card, chances are you will never see a master-key by logging as your card will not be in the current provider database and never be addressed. Most people log using their existing card/decoder combination and only see information intended for that card. Some decoders (Nokias with DVB2000) can log the whole data stream and can therefore see all master-keys being sent by the providers. This is very useful as it allows relatively easy access to MK data for anyone who has one of these boxes (or knows someone that has!). Some people logging almost full time have accumulated key databases with 500,000 entries, which must be close to every active card in service in Australia with any provider.
3. Plain (decrypted) Master Key (PMK)
This is the master-key that is actually stored on the card and is essential for continued viewing. Without the PMK, the card cannot decrypt keys and store them. The PMK is now considered the minimum requirement for viewing. A Provider ID and PMK can be added to expired or virgin cards and deliver pictures. Of course, the next MK update will kill the card as it has no ability to process MK updates. There are 256 cards in a Provider group and all have the same PMK so the last byte of the Provider ID used to add the PMK to a card can be anything. (remember a Provider Group is the first 2 bytes of a Provider ID)
At this point I will introduce the concept of memory locations (maps) for cards. The smart-card has defined locations for placing data which have been mapped. The PMK goes to key location 00. More about this later.
4.Plain or Session Keys
Keys updates are sent virtually continually now. It appears a pair of keys is always present on the card and one of these must always be valid for pictures to be delivered. It is because the keys are frequently changed that a PMK is essential for a card now. Keys cannot be decrypted and written to the card (as Plain keys) off air without a valid PMK being present.
It is feasible to decrypt keys and write them to the card but it is a fruitless exercise as changes will soon invalidate that key. Keys are placed in memory locations 02, 04, 06 etc (even numbered slots). More on this later. Without valid plain-keys the card will not accept any signatures which greatly limits what can be done to the card.
5. Channel ID
Having got this far you should be fairly familiar with this concept by now. Channel IDs can enable a channel (eg. Adult channel, PPV) or a group of channels. Likewise more than one Channel ID may enable a channel. This permits the providers to use completely different sets of Channel IDs to turn on the same shared channels. Channel Ids cannot be written to cards without at least one valid plain-key present as signature errors will result.
6Country Code
Country codes (for most decoders) determine what grouping of channels will be available (though not necessarily viewable, see ChIDs). The CoCo for each provider sets the channel lineup that can be selected for that provider. Setting it to almost anything else will normally permit all channels to be available. Recent changes by providers appear to be focussed on this area and its here that firmware changes to decoders have had an impact as has been found by some users of UEC decoders.