PCSC framework spy: broken since Mac OS X Yosemite

In "PCSC API spy, on Mac OS X" I proposed a way to spy on all PC/SC calls of an application.

A few months later Yosemite was available and my spying library does not work any more ☹.

PCSC framework replacement: fails

Example of failure:

$ DYLD_FRAMEWORK_PATH=/tmp pcsc_scan
PC/SC device scanner
V /Users/lroussea/Documents/sc/costa/pcsc-tools (c) 2001-2011, Ludovic Rousseau 
Compiled with PC/SC lite version: 1.4.0
SCardEstablishContext: Service not available.

Spy output (in a second terminal window):

$ ./pcsc-spy
SCardEstablishContext
 i dwScope: SCARD_SCOPE_SYSTEM (0x00000002)
 o hContext: 0x00000000
 => Service not available. (SCARD_E_NO_SERVICE [0x8010001D])  [0.000001109]
SCardReleaseContext
 i hContext: 0x00000000
 => Invalid handle. (SCARD_E_INVALID_HANDLE [0x80100003])  [0.000000006]

Results sorted by total execution time
total time: 0.001138 sec
0.001109 sec (  1 calls) 97.45% SCardEstablishContext
0.000006 sec (  1 calls)  0.53% SCardReleaseContext

If I run pcsc_scan alone, with no PC/SC spy, then the command runs as expected.

Something detects the usage of a new PCSC framework and rejects the first call. I guess the culprit is the original PCSC framework itself and this is a new security feature from Yosemite.

Running the application as root (using sudo) does not help.

SIP: System Integrity Protection

A new change since El Capitan is that the use of DYLD_FRAMEWORK_PATH does not work for programs in protected directories, like /usr/bin/.

$ type pcsctest
pcsctest is hashed (/usr/bin/pcsctest)

$ DYLD_FRAMEWORK_PATH=/tmp pcsctest

MUSCLE PC/SC Lite Test Program

Testing SCardEstablishContext    : Command successful.
Testing SCardGetStatusChange 
Please insert a working reader   : Command successful.
Testing SCardListReaders         : Command successful.
Reader 01: Gemalto PC Twin Reader
Enter the reader number          : ^C

Here the command succeeds but nothing is sent over the spy pipe.

In Yosemite I could use DYLD_FRAMEWORK_PATH=/tmp but with the same results as described above. On El Capitan the dynamic linker dyld just ignores DYLD_FRAMEWORK_PATH.

Another way to check that is to use lldb, the debugger provided with Xcode.

$ lldb pcsctest
(lldb) target create "pcsctest"
Current executable set to 'pcsctest' (x86_64).
(lldb) run
error: process exited with status -1 (cannot attach to process due to System Integrity Protection)
(lldb) quit

Conclusion

I know no way to spy the PC/SC calls done by an application on Mac OS X (with version >= 10.10).

This is problematic because PC/SC is still unstable on El Capitan. See "OS X El Capitan and smart cards: known bugs" for example. In some cases it would really help to know what PC/SC call returns an error to be able to:

• Report the error to Apple if it is a bug in PC/SC
• Tell the customer that it is a bug on Apple side
• Try to find a way to avoid the problem, if possible

PySCard 1.9.2 released

I just released a new official version 1.9.2 of pyscard. PySCard is a python module adding smart cards support (PC/SC) to Python.

The PySCard project is available at:

• sourceforge
• pypi
• github

Changes

1.9.2 (February 2016)

• Fix toBytes regression
• Fix installation using pip
• improve pydoc documentation
• user-guide.rst: use real sample codes
• minor improvements

I forgot to announce the previous version 1.9.1 on the blog.

1.9.1 (September 2015)

• Create a new version so that the upload to Pypi does _not_ contain the swig generated files.

Remaining problem

The versions 1.9.1 and 1.9.2 were supposed to fix  a problem when the software is installed using pip. But the problem is still present ☹.

The best way, for now, to install the software from source code is to use:

$ cd pyscard-1.9.2
$ python setup.py install

ATR statistics: TS, initial character

Article from the series "ATR statistics"

TS: initial character

The ISO 7816-3 specification is not public. So I can't copy/paste part of the text. I will use Wikipedia instead.

From Wikipedia https://en.wikipedia.org/wiki/Answer_to_reset#Initial_character_TS:

Initial character TS

The initial character TS encodes the convention used for encoding of the ATR, and further communications until the next reset. In direct [resp. inverse] convention, bits with logic value ‘1’ are transferred as a High voltage (H) [resp. a Low voltage (L)]; bits with logic value ‘0’ are transferred as L [resp. H]; and least-significant bit of each data byte is first (resp. last) in the physical transmission by the card.
For  direct   convention, TS is (H) L H H L H H H L L H (H) and encodes the byte ‘3B’.
For inverse convention, TS is (H) L H H L L L L L L H (H) and encodes the byte ‘3F’.
[ (H) represents the idle (High, Mark) state of the I/O line. The 8 data bits are shown in italic. ]
Bits in bytes following TS in the ATR, and further communications until the next reset, are numbered 1st to 8th from low-order to high-order, and their value noted 0 or 1, regardless of the chronological order and electrical representation, defined by TS. The bit following the 8 data bits in these bytes is an even parity bit, that is such that there's an even number of ‘1’ bits (H or L according to the direct or inverse convention defined by TS) among the 8 data bits and the parity bit.
TS also allows the card reader to confirm or determine the ETU, as one third of the delay between the first and second H-to-L transition in TS. This is optional, and the principal definition of ETU in the ATR of standard-compliant asynchronous Smart Cards is 372 periods of the clock received by the card

This first byte is used to indicate how bits and bytes are encoded at the electrical level: direct or inverse convention.

This choice has no impact on performances. As you can see, the vast majority of cards (94%) are using the direct convention (0x3B).

TS	#	%
0x3B	1945	93.87 %
0x3F	127	6.13 %