Results 1 to 5 of 5

Thread: ISO7816 coding query

  1. #1
    Senior Member gw1's Avatar
    Join Date
    Jan 2008
    Location
    Hobart
    Posts
    957
    Thanks
    49
    Thanked 608 Times in 213 Posts
    Rep Power
    267
    Reputation
    1901

    Default ISO7816 coding query

    Quote Originally Posted by P.M.
    i can get my program to talk via phoenix to the card - i can send commands and get replies...

    but i cant seem to send the commands to the receiver... i can send them to the receiver but i get no reply back...like i send the atr - technically the box should request for the coco right ?...doesnt respond to it... im thinking ive got the wrong kind of communication to the box ? im sending in hex value as bytes...

    in c#....using serialport class..
    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.

    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.

  2. The Following 5 Users Say Thank You to gw1 For This Useful Post:

    Gitch (23-09-09),mr.natrix (05-01-11),OSIRUS (05-07-09),Rocket (06-07-09),xfiles_2007 (05-07-09)



Look Here ->
  • #2
    Senior Member tagg's Avatar
    Join Date
    Jan 2008
    Location
    In a Tin Can
    Posts
    2,203
    Thanks
    872
    Thanked 378 Times in 221 Posts
    Rep Power
    308
    Reputation
    1897

    Default

    good post gw1, always learn something when you post

    Tagg

  • #3
    Junior Member
    Join Date
    Jan 2008
    Posts
    155
    Thanks
    2
    Thanked 8 Times in 7 Posts
    Rep Power
    204
    Reputation
    60

    Default

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

  • #4
    Senior Member Oscar's Avatar
    Join Date
    Jan 2008
    Posts
    656
    Thanks
    115
    Thanked 115 Times in 86 Posts
    Rep Power
    229
    Reputation
    524

    Default

    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.

  • #5
    Junior Member
    Join Date
    Jan 2008
    Posts
    190
    Thanks
    1
    Thanked 25 Times in 15 Posts
    Rep Power
    205
    Reputation
    81

    Default

    Quote Originally Posted by xfiles_2007 View Post
    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...
    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....

  • Similar Threads

    1. Virus query
      By gordon_s1942 in forum Security and Privacy
      Replies: 10
      Last Post: 17-05-09, 02:33 AM
    2. Query
      By Davidn in forum Security Alarms
      Replies: 6
      Last Post: 13-03-09, 05:29 PM
    3. Dual LNB Query
      By nickbo in forum Satellite TV General
      Replies: 5
      Last Post: 12-12-08, 09:04 AM
    4. Ram Query
      By myf360f1 in forum PC Hardware and Printers (including 3D Printers)
      Replies: 7
      Last Post: 21-04-08, 09:37 AM
    5. DVD query
      By kleinfranken in forum Sound/Visual/Digital Multimedia
      Replies: 3
      Last Post: 01-03-08, 01:22 PM

    Bookmarks

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •