THE MOSC COMPENDIUM- by Kuband

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.

4.0 The Story So Far….
Lets take a more detailed look at what you probably had to do to get pictures using the Newbie Guide and analyse those scripts.
4.1 Changing the Country Code.
To do this you probably used a script generated by CreaCRD or similar tool or maybe you wrote your own. Let's look at the content of a similar script.
01 01 00 00 00 10 c3 s0 00 0a 62 03 47 45 52 s1
This breaks down to:
01 01 00 00 00 10
= This is the basic 6 byte card instruction. These always start with 01 and the second byte identifies the class of command. In this case 01 means this is an entitlement management message (EMM). The last byte (highlighted) is the number of bytes that follow this command. In this case it is 10(hex) meaning there will be 16 more bytes in the string. You probably looked at the string and said that can't be right, I only count 10! That's because 2 components of the string are NOT bytes. s0 and s1 are programmer macros which we will look at shortly.
c3
= The C3 tells the card what data type is next. In this instance C3 means it will be using the hex serial number. There is a 4 byte ‘space’ reserved after this byte. This ‘space’ may be occupied by a hex serial (3 bytes) and a filler byte (00) or possibly a Provider Group (2 bytes) in which case another 2 bytes (00 00) will be needed as the filler. Some card commands can use either the Provider ID, Group or the Hex Serial Number
s0 00
= The s0 is the "Get hex serial" macro. This inserts the 3 byte Hex Serial Number already read by the programmer when it initialised the card. So, s0 represents 3 bytes of data in the string. The 00 is the filler byte mentioned above.
See Appendix A for a macro list.
0a
= The 0a(h) is the number of bytes to follow. In this case there will be 10 more bytes to follow in the string.
62 03
= This is a card nano command. This pair of bytes tells the card that the next 3 bytes are the new country code that must be written to the card. Note that the second byte (03) is a length byte for this nano ie. 3 bytes to follow the nano.
47 45 52
= The new country code. Translated to decimal equivalents from an ASCII table these bytes say ‘GER’ meaning Germany is the country code.
s1
= The last 'byte' in the string is not a byte but another programmer macro. This is the single most important programmer macro of them all and the real basis to altering data on most IrdetoÓ smart cards.
Here’s what it does:
You may recall from the Newbie Guide that there are 5 bytes in a signature. As it turns out, for V1.2,1.4 and 1.6 cards only, there is a command that gets the first four bytes of the correct signature from the card. With only one byte unknown, this only leaves a maximum of 256 combinations to test as opposed to the approx.1.1 trillion total possible signatures!
Therefore, in order to get a correct signature for a card, all we need to do is send the command requiring a signature to the card with the good 4 bytes plus a 5th variable byte, and if it’s incorrect, increment the variable byte and try again. Eventually, all being well, a correct signature will occur, the command will be completed and a correct response will be returned. So you can see that the s1 programmer macro represents 5 bytes in the script. Now the length bytes make sense!
So, in conclusion here’s a list of what the s1 macro does:

·Sends a command with a dummy signature to the card.
·Requests the good 4 bytes of signature from card.
·Inserts this into our script with, say, 00 as fifth byte and sends to the card.
·Checks the card response. There are defined response codes. (see Activate)
·If incorrect, increments the fifth byte and sends the script again.
·If correct, our script will be executed by the smart-card and a successful change occurs and the card sends a ‘signature correct’ response.

By now it should be fairly obvious that card programming software is not just a fancy version of Windows Terminal! The program must look at the total content of the script, check each programmer macro it finds and insert the results to ‘build’ the final script for transmission to the card. The s1 macro is always the last programmer macro processed as it uses the constructed host script to send to the card for signature byte detection. For long scripts (eg multiple ChID additions) this can be a noticeably slow process.
See Appendix A.

4.2 Adding Channel Ids
Lets look at this large script, now that you are becoming familiar with the process.
01 01 00 00 00 4b 03 p2 00 45 51 06 fe 09 00 00 ff 00 51 06 ff 60 00 00 ff 00 51 06 ff 61 00 00 ff 00 51 06 ff 62 00 00 ff 00 51 06 ff 7d 00 00 ff 00 51 06 ff d9 00 00 ff 00 51 06 ff e8 00 00 ff 00 51 06 ff fe 00 00 ff 00 s1
Actually, this is quite a straight-forward script, it just looks big! Here’s the breakdown….
01 01 00 00 00 4b
= Once again, the 6 byte instruction starting with 01 and it’s a class 01 command (an EMM). The length of the string to follow is 4b(h) or 75 bytes.
03
= Again, this byte identifies by what mode the card is to be addressed, in this case it is using the Provider ID.
p2 00
= The p2 is another programmer macro. In this case it gets the Provider ID which is inserted into the final card script. As the Provider ID is 3 bytes, the single 00 is a filler byte again. See Appendix A
45
= Another length byte. There will be 45(h) or 69 bytes after this point.
51 06 fe 09 00 00 ff 00
51 06 ff 60 00 00 ff 00
51 06 ff 61 00 00 ff 00
51 06 ff 62 00 00 ff 00
51 06 ff 7d 00 00 ff 00
51 06 ff d9 00 00 ff 00
51 06 ff e8 00 00 ff 00
51 06 ff fe 00 00 ff 00
= These strings write the channel ids. The 51 06 card nano is an instruction to write the channel id and date/timer data to the card. The second byte of this 2 byte nano is, again, the length of string following the command. In this case the string is obviously 6 bytes long (2 ChID +2 Date+2 Timer bytes).
The 2 byte ChID follows (the underlined bytes in the strings above). The 00 00 after the ChID is the effective card date of the ChID. Setting it to 00 00 means the ChID is effective since the card clock was started. This function is used to, for example, turn a channel on at a certain card date (eg for Pay Per View). The next 2 bytes FF 00 are the duration the channel is to be active. In this case FF means always on. Setting this to 00 will kill the channel.
s1
Here it is again! The signature is a common feature of most scripts that do useful things. No explanation should be necessary. See Appendix A also.


Notes
These explanations barely scratch the surface of the full command set that can be applied to a card. I have only picked two simple scripts you may already have used.
A few things should be noted. Often nano commands that are 40(h) removed from the one you are looking at have the same function. For example, the 50 06 command to write channels could be replaced with 10 06 or 90 06. This rule may not be universal but seems to apply to most nanos.
Another feature of command strings and responses is checksums. These are a single byte added to the end of a string and are the result of a calculation used to validate the string contents. Ordinarily they are of no concern as the programmer software knows how to deal with them. You need to be aware that they exist as you will see them often and may wonder where the extra byte came from.
Note also that obviously you can substitute the actual data for a macro. If you already know the correct signature then it can be used rather than the s1 macro. This removes the need to search.

4.3 Boring day to day activities
Well, more like minute to minute activities really! Lets look at what you will see when you start logging……
The first thing you will notice is that, regular as clockwork at around 10 second intervals (Pace box) something is sent to your card and it answers back. This is an Entitlement Control Message.
Here’s a complete ECM, as sent:
01 05 00 00 00 06 ff 55 00 02 00 20 05 d8 48 01 00 78 12 02 01 6f b9 14 16 63 7f 7f 12 5d ea c6 67 6a bd b8 3f e8 50 67 d8 87 3d.
Let’s pull it to bits:
01 05 00 00 00 06
= This is our standard 6 byte command string. The second byte (05) indicates it’s an ECM. In this case the 5th byte tells us that only one key is involved. The last byte is the length string but it should be obvious that there are more than 6 bytes in this ECM! In this instance, the 06 indicates there are 6 bytes until the next length byte. This may be a convenient way of dealing with strings of potentially variable length.
ff 55
= This is the Channel ID for the currently selected channel on the decoder, which this ECM is trying to get authorised. This is significant as it means whenever you want a Channel ID to add to your card, you just run the logger and select the channel on the decoder. Here it is, right in the ECM being sent to the card, even if the card returns an error.
00
= The Provider number. If you don’t already know it by now, Aussie smart cards have 2 providers numbered 00 and 10. Usually only one is used and its 00.
02
= The key number. You will remember I mentioned earlier that keys get put in specific places on the card. These are even numbered locations starting at 00 In this case, we are talking about the key at location 02.
00
= Another filler byte, it seems. It is always set to 00, apparently.
20
= The next length byte. Note that it is the 6th byte from the command string. It indicates there are 20(h) or 32 bytes to follow.
00 02 05 d8
= The first 2 bytes are a ‘set date’ instruction. Once again the second byte is a length byte. You will recall that there can be a 40(h) offset for the same command. In other strings you will often see 40 02 as the date setting bytes. Both work. The next 2 bytes are the current system date (05 d8).
48 01 00
= This nano is not understood at present. It would be reasonable to assume that 48 is the instruction, 01 is the length byte and 00 is the data. Possibly it refers to some activity to be performed using Pr 00. If anyone has any info on this let me know.
78 12
= Another nano. The first byte indicates there are keys to be decrypted and the channel checked against the card entitlements. The 12(h) is the length byte so we expect 18 bytes in total
02 01
= The first byte is the key number we are dealing with again (02). The second byte (01) indicates which of the two keys that follow is to be used. This indicates the second one is to be used. The options appear to be 00 or 01.
6f b9 14 16 63 7f 7f 12
5d ea c6 67 6a bd b8 3f
= Two encrypted 8 byte keys, one immediately follows the other in the string. This completes the count of 18 bytes in the nano string.
e8 50 67 d8 87
= These 5 bytes are the signature. These complete the byte count of 32 mentioned earlier.
3d
= The checksum. As I mentioned earlier, these will appear all the time but they are not part of any byte counts.
The Response

Every ten seconds or so, the ECM is sent and responded to. Here’s the response:
01 05 9d 00 38 00 00 0e ff 55 00 01 ff ff 1b 79 1b e8 ce a6 12 7a 9e
= This breaks down to:
01 05 9d 00 38 00 00 0e
= This indicates a correct response to an 05 instruction. The sixth byte is NOT a length byte in this case but indicates what key was decrypted. Its inverted so here it shows the second key was decrypted. The eighth byte 0e(h) indicates 14 bytes to follow.
ff 55
= The Channel ID being evaluated.
00
= Filler byte
01
= The key that was used for decryption in the original string (the second, here) and the inverse of the sixth byte referred to above.
ff ff
= Filler bytes, always ff ff, it seems.
1b 79 1b e8 ce a6 12 7a
= The decrypted 8 byte data, in this instance. Not of any immediate use to us, at present.
9e
= Checksum, again. Remember, its not counted in the length bytes.
Notes

Almost all the information needed to analyse scripts can be found in Activate. It can take some searching and it does need you to get a basic grasp of the concepts before you can fully interpret everything.
We could go on and analyse some more stuff but it is starting to get tedious so I will do something different. As an exercise have a look at the following logged communications and see if you can work out what is happening. Some nanos are underlined.

Logged from the box, about every minute at the moment:
01 01 00 00 00 23 02 04 f2 00 00 1d 40 02 05 d8 50 52 02 df e7 44 fe f4 91 13 02 04 a1 fe ff 15 44 0e cf f2 26 b1 1d a7 c3 05
Answer from the card:
01 01 00 00 3f 00 00 03 00 00 00 03
As a clue, this is an EMM update command.
If you are going to write scripts yourself you are advised to find a tool to help you do it. They can take the drudgery out of things like length byte counts. Many programs capable of scripting come with a lot of capability built in and can more than cater for most card programming needs. You can write or edit them from cold using WindowsÓ Notepad if you are so inclined. Programs like CardWizard are capable of more complex scripting and provide aids to help assemble the scripts.
5.0Memory Mapping on Smart-cards
I have mentioned the idea of memory mapping on smart cards. Whilst this is an advanced concept it is worthwhile that you have some idea of what is going on so at least you will know what other people are referring to!
Actually there are at least two ways that card commands can “talk” to smart card memory. The first is simply by using the key numbers (00, 02, 04, 06 etc) and is most normally used by the providers. The smart-card software knows where to place keys based on their number. The second mode is to directly address card locations. This is done by the ‘5f’ nano command. “Activate” only partly covers this so I will illustrate both modes with some simple examples. Since writing plain-keys in Australia is pretty much a waste of time, I will be brief with this bit. It is useful to recognise what the providers are doing
First Method
Here’s a script that writes key updates.
01 01 00 00 00 23 02 pg pg 00 00 1d 40 02 dd dd 50 52 02 kk kk kk kk kk kk kk kk 04 kk kk kk kk kk kk kk kk ss ss ss ss ss 05
This is broken down to the following:
01 01 00 00 00 23 02 pg pg 00 00
= The normal 6 byte command, 23(h) bytes to follow. The 02 indicates that Provider Group is the addressing mode so its there along with two 00 filler bytes.
1d
= 1d is the length of the rest of the string (29 bytes)
40 02 dd dd
= This sets the 2 byte card date, dd dd.
50 52
= This nano sets instructs the card that 2 keys are to be decrypted and written to the indicated locations. Note this is the same nano as 10 52 or 90 52.(The 40(h) offset)
02 kk kk kk kk kk kk kk kk
04 kk kk kk kk kk kk kk kk
= Next the two keys to go to locations 02 and 04 as indicated, once they have been decrypted. (A valid PMK for the group must be on the card). Software exists to readily decrypt these to PlainKeys.
ss ss ss ss ss
= the 5 byte signature, which concludes the total of 23(h) or 35 bytes of the string.
05 at the end, of course, is the checksum.
In Section 3 of this document I suggested you might want to analyse a string and the card response. Well, the above analysis is what you should have discovered if you did the suggested exercise!!

Second Method
The next script is the other way to write to card memory. It can best be described as direct memory addressing, to some degree bypassing the processing functions of the card. This script writes a PMK and PrID to a V1.2 card. Lets look at what happens.
// Plain Masterkey 00 - Provider ID pp pp pp - for ACS 1.2
= This is a sample of a remark. The // at the beginning tells the programmer software to ignore the rest of the line.
01 01 00 00 00 27 03 P2 00 21 5f cc 25 00 mk 26 mk mk 27 mk mk 28 mk mk 5f cc 29 mk 00 1A pp pp 1B pp 00 1C 00 00 s1
Without spending too much time on detail, this breaks down to:
01 01 00 00 00 27 03 p2 00 21
The standard 6 byte EMM command with a script length byte of 27(h). The 03 specifies addressing by Provider ID and the p2 inserts the current card PrID followed by the 1 byte filler and another length byte, 21. Note that we could have addressed the card by Hex Serial Number in which it would have been c3 followed by the s0 macro and the one byte 00 filler.
Now for the interesting bit:
The 5f cc byte pair tells the card that the following data is to be written to the specified locations. It appears that only 4 locations (8 bytes) are usually written using a 5f cc nano. Each location holds 2 bytes, as illustrated below:
5f cc
25 00 mk
26 mk mk
27 mk mk
28 mk mk

5f cc
29 mk 00
1A pp pp
1B pp 00
1C 00 00
s1
You can see this is a PMK as the first byte is 00, and note that the key is written as byte pairs to the numbered locations. There is the 5f cc command for the second 8 bytes (Note: it’s 5f c3 if this is a plain-key) but take note of the last 3 memory locations. These are the new Provider ID and some 00 fillers. You should know what the s1 is for.
Notes
So, there you have both the methods. The providers use the first one all the time. This is the key update command being sent regularly at the moment. Without a valid PrID and PMK on the card, this command will not be processed. This is what auto-updating is all about. It is this command string that new blockers must allow to pass through in order to keep the service. Blockers still need to stop CoCo changes and deal with ChID changes correctly to be really useful. Emulators have no such problems.
Some people have taken the time to map almost all the locations. This must have been a time consuming process requiring sending and testing responses (and probably crashing the odd card or two!) A V1.2 memory map is included at the end of this document. (Appendix B) If you study this you will see the key locations for both card providers and where all the Channel IDs are also stored. Note that the map starts at 72. It would be reasonable to assume that the locations prior to that hold card details or buffer areas.
6.0 How Some Things Can Be Done.
There are a number of ‘standard’ scripts around the place. A file with some of these should accompany this article. These scripts do a number of potentially useful things if you get right into scripting. They can also do some damage if used incorrectly so handle with care! Note that many of these functions are now built into programmers such as Allsat or CardWizard.
To help you along a bit, here are some techniques that you may find useful. As always, I don’t claim to be the expert in all this. People are coming up with new ideas all the time and as more is known, some old ideas changed. If you know a better way then let me know or at least tell me if it won’t work and why!!
How to:
1.Read or Change Country Code.
This is a standard feature of most scripting/programmer software. Use CreaCRD or CardWizard.
2.Read or Change Current Channel Ids
This is a standard feature of most scripting/programmer software. Use CreaCRD or CardWizard.
3.Decrypt a plain master-key (PMK).
You require card data and the Masterkey and the subscribed card. Use KeyDecrypt.
Note: Cardwizard will also extract a PMK from a V 1.2 card. Same screen (Algo) as used for HMK.
4.Find a Hex Master Key
You need CardWizard. You may need to adjust timing settings. Try 1500/50
5.Add PrID and PMK to a card.
You can add these using CreaCRD or Cardwizard.
6. Kill a Card.
Pull, insert while running a script continuously. Cardwizard can help you here with its Kill00 command button. Eventually you will get no ATR.
7. Resurrect a killed Card (No ATR).
Use Re-animator in CardWizard. Pull & Insert card while watching for ATR in the window. This may take time but I have made it work a few times. After ATR all other data should be zeroes. Allsat also has a reanimate function.
8. Add all FFs to a Zeroed Card.
Use SuperFF in the attached files. It’s also in some programming software eg. Allsat.
9.Restart the Zeroed(FF) card.
Use Sinexpert from the attached files. May need to run twice and/or clear buffers. Then add PrID/PMK, CoCo and ChIDs.
10.Add second provider to cards.
Need valid PrID and PMK for second provider. Write to card with CreaCRD or CardWizard. Add ChIDs to second provider.
11. Log card communications.
Use a season interface or other logger board (or my 1 wire logger mod). Use CardCom, one of the easiest loggers to use.
12.Use an emulator.
You need a season interface (or my Seasoned Pace mod) and software. CardEMU works well, also Voyager. All need a PrID and PMK and can use a HMK to auto-update MKs.

13Clone a Card
If you can borrow a subbed V1.2 card for long enough to analyze it, you can make a working copy. You need a zeroed V1.2 card. As long as the subscription is maintained, your card will get MK updates and permit you to carry on your experiments. Allsat and CardWizard have clone buttons (never tried) Other software does this (have used). Need HMK, PMK, Hex Sn, Ascii Sn.
Appendix A Macro Commands / Card Address Modes
Here is a list of the programmer macros:
R0 - Initiate card reset. If the card is OK it replies with the ATR (Answer to Reset).
// - Used for remarks.
P0 - Get Card's set Provider Group 00 and put it here (2 Bytes)
P1 - Get Card's set Provider Group 10 and put it here (2 Bytes)
P2 - Get Card's set Provider ID 00 and put it here (3 Bytes)
P3 - Get Card's set Provider ID 10 and put it here (3 Bytes)
S0 - Put the HEX serial number here (3 Bytes)
S1 - Put the 5 byte digital signature here and check the value of the final byte.
T0 - Put the date stamp of Provider 00 here (2 Bytes)
T1 - Put the date stamp of Provider 10 here (2 Bytes)
I0 - Opens an input window so that you can enter HEX data. The length of the data string must be correct.
Parameter Format: IO Text_can_be_written_here_without_spaces,_always_end_with_;
Here is a list of the card address mode selector bytes with filler bytes required.
# Card Data used: 4 Byte content To insert automatically:
02 Provider group of provider 00 (2 bytes) +00 00 Use crd macro p0
03 Provider ID of provider 00 (3 bytes) +00 Use crd macro p2
0A Provider group of provider 10 (2 bytes) +00 00 Use crd macro p1
0B Provider ID of provider 10 (3 bytes) +00 Use crd macro p3
C3 Hex Serial Number (3 bytes) +00 Use crd macro s0

[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]