|
Part Three:
------------------------------------------------------------------------------------
INS 3 Commands
01 03 xx xx xx xx
The return code to these commands appears to be different from the INS 01 commands.
These commands may only work on corrupted cards.
--------------------------------------------------------------------
INS 4 Commands Set...
01 04 00 00 00 14 3x 3x 3x 3x 3x 3x 3x 3x 3x 3x 43 36 35 31 30 36 41 20 20 20
Changes ascii serial no. to xxxx xxxx xxy This only works for defective cards without write protection. That is with all data FFFFFFF or 000000.
Change the 10 "x" to the new ascii serial number. Leave off the last "y", it is some form of checksum calculated by the card. Only if you enter the correct ascii SN (as printed on the card) is the last checksum byte correct.
If this string doesn't work swap the last bytes after the 43 to:-
//43 37 30 32 32 32 41 20 20 20 for ???
//43 36 33 39 30 36 41 20 20 20 for ???
//43 36 31 36 32 33 41 20 20 20 for ARE
//43 36 31 30 31 38 41 20 20 20 for ZAF
01 04 01 00 00 00: Activates write protection
Answer is 01 04 42 00 01
01 04 00 00 00 00: Asks card if it is "write protected".
Answer 01 04 40 - not protected.
Answer 01 04 41 - protected.
If you attempt to write a new Ascii SN to a write protected card, the return code is "41" - write protected. However the data is written into the buffer. The Ascii SN is not changed. Use DumpBuff0708.crd to read contents of the buffer.
"Write protection" has nothing to do with blocking EMMs. I believe it is to do with the basic BIOS of the card. Variable data such as keys, dates, channel IDs etc are written to the eeprom of the card and these parts are not protected.
--------------------------------------------------------------------
INS 5 Commands ECMs (Entitlement Control Message)
01 05 00 00 xx xx: Sends the channel ID, provider identifier, key number, date and the key to be decrypted.
--------------------------
Here follows a full description of the decryption process. Thanks to two anonymous contributers.
In the initial exchanges between the cam and the card, the cam sends the Cam Key with this command
Sending: IRD/Cam Key
01 02 09 03 xx 40
00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01
02 02 02 02 02 02 02 02 03 03 03 03 03 03 03 03
04 04 04 04 04 04 04 04 05 05 05 05 05 05 05 05
06 06 06 06 06 06 06 06 07 07 07 07 07 07 07 07
The xx = 00 to 07. The value of xx determines which of the eight byte strings the card is to use for the decryption process.
So in 01 02 09 03 00 40 bytes 00 to 07 are used (00 00 00 00 00 00 00 00)
01 02 09 03 01 40 bytes 08 to 15 are used (01 01 01 01 01 01 01 01)
01 02 09 03 02 40 bytes 16 to 23 etc..
However, in some systems xx is always 00 and only the first eight bytes are used. In these systems the 40h bytes of the cam key always seem to have the same value. In other systems (CI -cams and UEC decoders etc) the value of the cam key changes every time it is reset. Anyone know the algorithm for this. Is it pseudo-random or are there a set number of different cam keys?
If the card and the cam are all in order. Then the card accepts the key with:-
Card Accepting IRD/Cam Key
01 02 55 00 09 xx 00 00 6y
The 6y is the CRC byte (checksum).
If there is an error then the return from the card is:-
01 02 57 .....
and no decryption or picture can occur.
--------------------------------------------
|