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.