From: David L. Markowitz (davrttrek.com)
Date: Thu Sep 04 2008 - 16:57:29 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I noticed that the available documentation of SCardTransmit() and
IFDHTransmitToICC() differ WRT RecvPci.

As documented on MSDN and other places, SCardTransmit() has as its fifth
argument:

          __inout LPSCARD_IO_REQUEST pioRecvPci

This is described as:

     pioRecvPci [in, out]

     Pointer to the protocol header structure for the instruction, followed
     by a buffer in which to receive any returned protocol control information
     (PCI) specific to the protocol in use. This parameter can be NULL if no
     PCI is returned.

OTOH, as documented by the PC/SC workgroup, and in the MUSCLE PC/SC IFD
Driver API, IFDHTransmitToICC() has as its seventh arg:

        PSCARD_IO_HEADER RecvPci

        RecvPci INOUT Receive protocol structure

# RecvPci - contains two structure members

     * Protocol - 0, 1, ... 14

       T=0 ... T=14

     * Length - Not used.

Even worse, the CCID IFDH defines IFDHTransmitToICC() this way:

PCSC_API RESPONSECODE
IFDHTransmitToICC(/*unused*/ DWORD Lun, SCARD_IO_HEADER SendPci,
         PUCHAR TxBuffer, DWORD TxLength,
         PUCHAR RxBuffer, PDWORD RxLength,
         /*unused*/ PSCARD_IO_HEADER RecvPci)

In the function body, RecvPci->Protocol and RecvPci->Length are never set
to anything. SCardTransmit() passes in a temp space struct, and returns
it unchanged and unchecked to the caller if a non-NULL was passed in.

We have found some middleware that depends on at least RecvPci->Protocol
being set.

So, should these values be getting set? Should they match what was passed in
as SendPci? Or is the middleware broken?

--
     David L. Markowitz
     davrttrek.com
_______________________________________________
Muscle mailing list
Musclelists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]