THE MOSC COMPENDIUM- by Kuband

[Snow]

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!!

[Snow]

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.

[Snow]

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

[Snow]