Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.
You can find a brief explanation abour one of scrambling system ( Old one ) and take care that it is for educational only !
Seca Mediaguard
* View a sample communication with the Smart Card (using MKFind log).
* A complete overview of all Seca INS & Nanos (thanks Adrian64 my Friend).
* A listing of all known Seca Startup Records.
* Sample of a manual V6 card extraction (thanks to Kcplus and Satgirl).
This is a brief overview of the Seca Mediaguard systems structure. For more detailed information you may want to download several documents from the other download section.
Initializing the card:
The card plays a crucial role in the communication process between the CAM and the card in the sense that the card dictates how the communication should take place.
Upon every reset, the card will make itself known to the receiver/CAM. A reset is triggered, the moment the receiver is turned on, but also every time the card is pulled from and then reinserted into the CAM.
What happens upon a reset of the card is the following: The card will tell to the receiver how it needs to be updated. This notification to the CAM is defined in the ISO7816-3 specifications and it is very strict. The information, according to the ISO protocol, contains for instance the specification what Voltage and Amperage are needed to update the card. But it will also tell the CAM at what Baudrate and whether the communication should be synchronous or asynchronous etc.
The Seca Mediaguard algorithm:
The Seca Mediaguard algorithm is based on a 8 byte long coded key; the so called Crypted Controlword. From this Crypted Controlword, the Decypted Controlword is computed. For that computation, a 16 byte key is needed. The 16 byte key is composed of 2 8 byte keys, called the Primary Key (PK) and the Secundary Key (SK) respectively.
Then there are 2 more important sets of keys to be mentioned: The Operational Keys (OK) and the Management Keys (MK). The OK are the actual keys that will open up your channel. The MK are the keys that will make your OK change automatically when the provider sends the necessary signal.
Then, last but not least, we need to mention the Provider Keys and the Seca Keys:
Provider Keys are those keys that enable the provider to activate, modify or disable a card. But only operations within 1 provider are possible with those keys.
The Seca Keys are the keys that authorize adjustments to a card on all levels. So with the right Seca Keys, it is possible to even add or remove providers, not just modify them.
How does the communication work:
When the communication protocol of the card is known to the CAM, the CAM will start giving instructions and asking information. The instructions that the CAM will send to the card, are called Instruction Bytes or INS for short. A very comprehensive listing of all INS is to be found in the download section (Seca FAQ Duits.zip), but it is in German. Not quite as comprehensive but good for starters is the English document in the download section, called Mediaguard Musings Engels.zip.
As mentioned above, the card will start sending information to the CAM upon reset. The message it sends is called the ATR which is short for Answer To Reset. As soon as the ATR is received by the CAM, the CAM will start requesting information from the card. That can be information about which providers are supported by the card, what authorization does the user have for a selected provider etc. etc.
Let's give an example of such a communication:
One of the requests a CAM will make for instance is the request for information about supported providers.
The INS for requesting provider info is 12 (hex). The standard notation for hex is 0x. So hex 12 will be written as 0x12.
The complete syntax for Seca Instruction 12 (or INS 12) would be 12: C1 12 xx 00 yy where:
- C1 12 means INS 0x12
- xx is the provider number for which the information is requested. 00 is SECA.
- yy is the number of bytes the answer should contain.
Syntax for the answer is: 12 bb bb cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 00 dd dd ee ff ff 90 00
where:
- 12 is the INS identification for the answer. (in other words, it says "this is an answer to request 12).
- the 90 00 at the end of the string is standard Seca and means "everything is OK".
- in between there are exactly the number of bytes as specified in the INS (so yy bytes, see above)
- bb bb is the Provider ID.
- cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc is the Provider name.
- dd dd is the Smartcard Address.
- ee is yet unknown.
- ff ff contains the end-date of the subscription.
So, the the following INS:
C1 12 01 00 19 would mean:
- give me information about the first provider in the list
- and make sure the answer contains 25 bytes (19 hex).
- answer to INS 0x12 is
- Prov.ID is 00 04
- Name is CANALSATELLITE
- Smartcard Address is FF FF
- Subscription ends on 31.12.2001
Well, that should be enough to give you some idea as to how Seca communication is structured.
It will probably give you an idea of what interesting stuff there is to learn about those small cards.
For a nice example of how a Seca instruction is executed, you can have a look in the software chapter. There you'll find a page called MOSC cloning. At the end of that page there is an example of a Seca INS to change the cards serial number.
OK, have fun )
Seca Mediaguard Sample Communication
View a sample Seca communication with a Smart Card (using MKFind log).
If you start MKFind and connect to your card, the card will make itself known by sending the ATR.
Upon receiving the ATR, the CAM or in this case the MKF software will start requesting information.
MKF keeps a nice log of this communication.
I will use this log to explain a bit more about Seca INS.
This is how such a MKF log file looks:
*****************************************
MKF v4 Log File
10-okt-2001 13:53:29
*****************************************
<- 3B F7 11 00 01 40 96 54 30 04 0E 6C B6 D6 90 00
-> C1 0E 00 00 08
<- C1 0E 00 00 08 0E 00 25 00 00 00 07 5B CD 90 00
-> C1 0E 00 00 08
<- C1 0E 00 00 08 0E 00 25 00 00 00 07 5B CD 90 00
-> C1 16 00 00 07
<- C1 16 00 00 07 16 00 00 00 01 00 00 FF 90 00
-> C1 12 00 00 19
<- C1 12 00 00 19 12 00 00 53 45 43 41 20 20 20 20 20 20 20 20 20 20 20 20 00 00 00 00 00 00 00 90 00
And this is how the information 'translates' into plain English. Let's explain them line by line:
3B F7 11 00 01 40 96 54 30 04 0E 6C B6 D6 90 00
Message:
This is the cards ATR string, it is sent after every reset.
C1 0E 00 00 08
Question:
What is the Card Serial also called Unique Address (UA)??
The answer should be 8 bytes long.
C1 0E 00 00 08 0E 00 25 00 00 00 07 5B CD 90 00
Answer:
The red bytes are the actual 8 bytes that were requested.
The last 4 bytes of that string contain the UA.
C1 0E 00 00 08
Question:
Same as above.
Don't ask me why MKF requests this information twice.
C1 0E 00 00 08 0E 00 25 00 00 00 07 5B CD 90 00
Answer:
Same as above.
C1 16 00 00 07
Question:
How many providers are supported on the card??
The answer should be 7 bytes long.
C1 16 00 00 07 16 00 00 00 01 00 00 FF 90 00
Answer:
Bytes 3 and 4 contain the actual number of supported providers.
So in this case ther is only 1 provider supported on the card.
More to this further down.
C1 12 00 00 19
Question:
Request information about provider 00.
The answer should be 19 bytes long (19 hex is 25 decimal).
C1 12 00 00 19 12 00 00 53 45 43 41 20 20 20 20 20 20 20 20 20 20 20 20 00 00 00 00 00 00 00 90 00
Answer:
The first part of the answer (red) contains the name: 53 45 43 41 means SECA (hexadecimal notation)
The second part (purple) is in fact composed of 3 other separate strings:
- the first 4 bytes are the Card Serial (UA)
- the next 2 bytes contain the end-date of the subscription
- the last byte contains the region code
OK then one last thing to explain.
How to determine the number of provider on the card from the answer you get.
This is where it gets a bit more difficult.
You will need a scientific calculator.
You can use the Windows calculator in scientific mode.
As we have seen above, the answer for the number of providers here is 00 01.
The 2 bytes should be considered as one word.
This word should then be converted from hexadecimal to binairy.
So in the scientific calculator type in the answered bytes (in hex) and the convert them to binairy.
Try that if the hex value of these two bytes would have been 00 03.
Converted to binairy that gives you 11.
Just simply count the number of bits in this string and you have the number of providers on the card.
So 2 bits set (11) means that there are 2 providers supported on the card (provider 0 through provider 1).
OK, everything clear so far?? Well then let's go on.
What would the number of providers on the card be, if the 2 byte answer would have been 01 FF.
Just type in on your calculator 1FF (in hex) and convert to binairy.
You will notice that the binairy value is 111111111.
Well, this answer says that 9 bits are set, or in other words, 9 providers are suported (provider 0 through provider 8).
So then what is the maximum number of providers that can be on one card??
Type FFFF on your calculator and convert to binairy.
Notice that the answer is 1111111111111111, so 16 bits set, or 16 providers supported (provider 0 through provider 15).
Well then, I hope this helps to understand a bit more about SECA communication.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
) 
