Gitch (23-09-09),mr.natrix (05-01-11),OSIRUS (05-07-09),Rocket (06-07-09),xfiles_2007 (05-07-09)
The main thing to understand is that smartcard protocol is master-slave with the card host being completely in charge of communication. Apart from the ATR, which follows reset pulse, the card sends messages only in response to commands received from the host. The card never initiates communication.Originally Posted by P.M.
If you haven't done so already, you need to thoroughly read the from start to finish and make notes. You're wasting your time trying to code without being on top of the specification.
[320K PDF] for one of ST's smartcard controller ICs is a good companion to the specification, fleshing out some of the issues in practice.
The specification takes you as far as basic message formatting, but for the application level protocol (unless you're implementing on of the standard applications such as file storage) you basically need to log and reverse the exchange between the card and host you're interested in. For Pay TV provider cards the cryptosystems (Viaccess, NDS, Irdeto, Seca etc) are proprietary and not documented except for the occasional paper by hackers, such as 007.4's for Irdeto 1.
A good way to approach and study such systems is to write a proxy, storing the card's ATR, serving it to the host after reset, then forwarding receiver commands and card responses back and forth, logging as you go. That gives you opportunity to get familiar with the messages and gain experience with the timing and error handling issues without having to understand everything first.
Most card tools are written in Delphi, VB6 or C++Builder. C#'s runtime may be sluggish on some PCs but you might as well give it a go.
To begin with I recommend you use phoenix & season with motherboard RS232 ports (eg COM1 & COM2) rather than USB serial adapter as they can be problematic. Stick to standard clock rate for your Phoenix (6MHz for Irdeto, 3.58MHz for NDS & Viaccess etc). Prototype your season code using a receiver that uses standard 9600 baud, eg Humax 54x0 for Irdeto uses 6MHz with is good, but Humax IRACE operates at higher frequency which means a non-standard baud rate is required.
Down the track you may want to spend time disassembling some of the cardsharing applications to learn some of their tricks. But that's a fair way down the track and whether it's necessary depends very much on what you're trying to achieve.
Gitch (23-09-09),mr.natrix (05-01-11),OSIRUS (05-07-09),Rocket (06-07-09),xfiles_2007 (05-07-09)
Look Here -> |
good post gw1, always learn something when you post
Tagg
ok i can send individual commands to the card and get replies ...
I guess the next part is controlling the incoming and outgoing data on the serialport event handler..the buffer is sending in a random set of bytes (such as 14 bytes followed by 6 bytes... 14 seems to be the max).. and cluttering the incoming and outgoing data all together...whats the best ways to control incoming and outgoing data...and isolate the ingoing and outgoing packets? create a method to process the buffer to match certain conditions.. ?
Thanks...
Why not hunt down the old V17 or ausgold source.
The listen and talk stuff and the timing stuff is in there and it works.
With any comms, it pays to understand the packets you are dealing with prior to doing it your self.
Most RS232 objects support the basic.... wait for x bytes. But how many.
In a perfect world, you will know what you want and only get those bytes.
When writing to a smart card, the reader will most likly echo back the command, then send the reply if any. If the command is OK it should reply, but sometimes it wont... so you will need to timeout your wait for x bytes.
This is not a valid command, just an example "SEND TO CARD".
01020000ln<len bytes><cs>
where
ln = length of data bytes to follow
len bytes = the actual number of bytes
cs = check sum
A reply my look like
010200000000ln<len bytes>cs
ie: the reply may not be the same format, it could be longer, shorter ...
Again this is just made up...
Command to send
Buffer = 01020000050102030405AA
Send to this to the card with something like
write (commhandle,Buffer,11) // ie: there is 11 bytes in the buffer
len = read (commhandle,Buffer,11,timeout) // Read the echo
You may need to do more then one read if the timeout is too short....
What we dont know is the lenght of the reply, but we do know the len of the reply header (in this example 7)
so,
len = read(commhandle, buffer,7,timeout) // Get the fist 7 bytes.
DataLen = Buffer[6]; // in c buffers start at 0
len = read (commhandle,&buffer[7],DataLen+1, timeout)
// Note &buffer[7] so I append the data to the header
// DataLen+1 to include the cs
At any time you need to decide if you loop and wait for the data or give up.
You should ALWAYS flush the comport input and output buffers prior to your next send.... this should ensure all extra packets not dealt with last time are cleared.
When you are in "server" mode, ie: waiting for a command, you will need to wait-for-data, then read the expect bytes....
Of course you could read and write 1 byte at a time, and just build up the packet, but there is less io when reading more at a time....
Bookmarks