This post returns to the problem of capturing traffic between a Windows and a smart card and looks at the nuts-and-bolts of logging such communication. A simplifying assumption is that all applications go through PC/SC API to communicate with the card. This is partially enforced by the smart card driver architecture in Windows, as each driver is given a handle to an existing card connection when invoked. But there also exist hardware such as USB tokens, which do not advertise themselves as CCID devices, and therefore are not considered “smart cards” according to the OS. Typically these devices are accessed via proprietary vendor code using a different USB class such human-interface device (HID), by passing the OS stack. The approach described here will not capture such communication.

MSDN documentation on PC/SC API indicates that the functionality is implemented in the winscard.dll binary. Looking at the list of function, a few entry points stand out: connect to the card, transceive (send a command APDU and receive a response APDU in return) and close the connection. For ad hoc experiments, setting breakpoints on these functions and dumping the memory regions corresponding to the input/output buffers would suffice. A sketch of the process if one were walking through it manually:

Continue reading →