T0/T1 marshaling confusion #31

leifj · 2016-10-17T20:15:28Z

I've been tracking a strange issue that I believe is due to a problem in the swig code for scard. I'm talking to a SLE5542 using an ACR39U reader and I've got a piece of C code for reading memory off of that card that works but the corresponding python code using the scard interface does not. All of this was done using fresh clones of pcsc-lite and pyscard from github.

The C code is in https://gist.github.com/leifj/140f9c79d99af078c5167f587cd81b69

This code works as expected and it depends on using the T0 protocol which triggers the correct processing of "pseudo" APDUs in the driver. So far so good. However ...

Using scard I expect code like this to work:

hresult, hcard, dwActiveProtocol = SCardConnect(
                hcontext,
                reader,
                SCARD_SHARE_DIRECT, SCARD_PROTOCOL_T0 | SCARD_PROTOCOL_T1)

SELECT_CARD_TYPE = [0xFF,0xA4,0x00,0x00,0x01,0x06]
hresult, response = SCardTransmit(hcard, SCARD_PCI_T0, SELECT_CARD_TYPE)
if hresult != SCARD_S_SUCCESS:
    raise error, 'Failed to transmit: ' + SCardGetErrorMessage(hresult)

Using this code I get a protocol mismatch (between the card protocol and requested protocol) and when I step through pcscd with gdb while running this python code, I find that the message string received by ContextThread in winscard_svc.c has a '1' in the pioSendPciProtocol field instead of the expected 0. A sample gdb snippet:

13553973 winscard_svc.c:351:ContextThread() Received command: TRANSMIT from client 14
353                     switch (header.command)
(gdb) 
621                                     READ_BODY(trStr)
(gdb) 
623                                     if (MSGCheckHandleAssociation(trStr.hCard, threadContext))
(gdb) p trStr
$3 = {hCard = 1821360693, ioSendPciProtocol = 1, ioSendPciLength = 16, cbSendLength = 6, ioRecvPciProtocol = 3, ioRecvPciLength = 16, 
  pcbRecvLength = 65548, rv = 0}
(gdb) c
Continuing.

Continuing to step through this I confirm that the subsequent call to SCardTransmit is attempted using the T1 protocol which of course results in a protocol mismatch later on.

There seems to be a marshalling error somewhere in pyscard.

The text was updated successfully, but these errors were encountered:

leifj · 2016-10-18T06:53:54Z

A bit more research... The '1' in dwProtocol for T0 is is clearly correct. The question is why 0 is sent from that piece of C-code, because that seems to be why the C code works.... Here is the same snippet of gdb from stepping through pcscd when calling the C program:

03558356 winscard_svc.c:351:ContextThread() Received command: TRANSMIT from client 14
353                     switch (header.command)
(gdb) 
621                                     READ_BODY(trStr)
(gdb) 
623                                     if (MSGCheckHandleAssociation(trStr.hCard, threadContext))
(gdb) p trStr
$1 = {hCard = 781293158, ioSendPciProtocol = 0, ioSendPciLength = 6299704, cbSendLength = 6, ioRecvPciProtocol = 3, ioRecvPciLength = 16, 
  pcbRecvLength = 266, rv = 0}

LudovicRousseau · 2016-10-18T07:48:33Z

Why don't you use the value returned by SCardConnect() in dwActiveProtocol to use it in SCardTransmit() ?

LudovicRousseau · 2016-10-18T07:52:35Z

You are using SCARD_SHARE_DIRECT. This imply a different protocol negotiation.
But that does not explain why the C code "works".

leifj · 2016-10-18T07:53:43Z

Sure but the case statement in _Transmit in scard.i makes that impossible

leifj · 2016-10-18T07:54:31Z

Yes but I use SCARD_SHARE_DIRECT in the pyscard code too - I just left that out for brevity

leifj · 2016-10-18T08:23:01Z

dwActiveProtocol is 0 btw which hits the default case in _Transmit and causes an Invalid Parameter exception. This seems inconsistent with the behaviour of the C library where passing 0 while using DIRECT triggers the desired behavior in the driver

leifj · 2016-10-18T09:04:12Z

Here is a patch that "fixes" this. Review pls...

diff --git a/smartcard/scard/scard.i b/smartcard/scard/scard.i
index 76f63ad..87f38fa 100644
--- a/smartcard/scard/scard.i
+++ b/smartcard/scard/scard.i
@@ -672,8 +672,12 @@ static SCARDRETCODE _Transmit(
 )
 {
     PSCARD_IO_REQUEST piorequest=NULL;
+    SCARD_IO_REQUEST unknown;
     long ret;

+    unknown.dwProtocol = 0;
+    unknown.cbPciLength = 0;
+
     pblRecvBuffer->ab = (unsigned char*)mem_Malloc(MAX_BUFFER_SIZE_EXTENDED*sizeof(unsigned char));
     pblRecvBuffer->cBytes = MAX_BUFFER_SIZE_EXTENDED;

@@ -692,6 +696,10 @@ static SCARDRETCODE _Transmit(
             piorequest=(PSCARD_IO_REQUEST)myg_prgSCardRawPci;
             break;

+        case 0x00:
+            piorequest = &unknown;
+            break;
+
         default:
             return SCARD_E_INVALID_PARAMETER

LudovicRousseau · 2016-10-21T19:28:45Z

I guess your C code works because you go in the default case and pioSendPci is not initialized.
With luck you have pioSendPci.dwProtocol = 0 and 0 is SCARD_PROTOCOL_UNDEFINED.

What is the value of dwActiveProtocolafter the SCardConnect()?

If you add a the line pioSendPci.dwProtocol = SCARD_PROTOCOL_T0 before the switch(dwActiveProtocol) the C program should also fail. Do you confirm?

leifj · 2016-10-25T18:25:59Z

Skickat från min iPhone

21 okt. 2016 kl. 21:28 skrev Ludovic Rousseau notifications@github.com:

I guess your C code works because you go in the default case and pioSendPci is not initialized.
With luck you have pioSendPci.dwProtocol = 0 and 0 is SCARD_PROTOCOL_UNDEFINED.

What is the value of dwActiveProtocolafter the SCardConnect()?

If you add a the line pioSendPci.dwProtocol = SCARD_PROTOCOL_T0 before the switch(dwActiveProtocol) the C program should also fail. Do you confirm?

Oh I'm absolutely sure you're right!

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

LudovicRousseau · 2016-10-26T09:54:06Z

What is the value of dwActiveProtocol after the SCardConnect()?

You forgot to answer this question.

LudovicRousseau · 2016-11-07T19:28:08Z

I got no answer?
I need to understand the problem in order to fix it correctly.

leifj · 2016-11-07T19:32:13Z

On 2016-11-07 20:28, Ludovic Rousseau wrote:

I got no answer?
I need to understand the problem in order to fix it correctly.

sorry, got several NMIs

leifj · 2016-11-23T22:44:29Z

Really sorry for the delay!

repr(dwActiveProtocol) == 0L after ScardConnect

If the connection to the card/reader was done using SCARD_SHARE_DIRECT then the card protocol has not been negociated and is undefined. This is not an error and _Transmit should not fail in this case. For example this is used to read/write memory cards. Thanks to Leif Johansson for the bug report. "T0/T1 marshaling confusion" #31

LudovicRousseau · 2016-12-01T15:44:21Z

It should be fixed with fa3addb

Please confirm it works for you.

LudovicRousseau · 2017-01-02T20:22:59Z

Can you please confirm the fix works for you?
The idea is to close this issue and release a new version of PySCard.

leifj · 2017-01-02T21:01:38Z

Actually it doesn't. I still needed my patch to make it work.

LudovicRousseau · 2017-01-05T15:09:27Z

Your patch should not apply without modifications on the latest version.

Are you really using the latest PySCard git version?
If yes can you send me your updated patch for review?

leifj · 2017-01-05T17:14:52Z

Skickat från min iPhone

5 jan. 2017 kl. 16:09 skrev Ludovic Rousseau ***@***.***>: Your patch should not apply without modifications on the latest version. Are you really using the latest PySCard git version?

Yeah I'm pretty sure

If yes can you send me your updated patch for review?

Exactly the same one the one in my PR

…

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

LudovicRousseau · 2017-01-06T12:53:35Z

OK. You PR can apply cleanly.
But your patch should have NO effect since the case 0 (or SCARD_PROTOCOL_UNDEFINED) is already managed by the current code.

I also note that your repository at https://github.com/SUNET/pyscard/commits/master is NOT up to date.

LudovicRousseau · 2017-01-27T13:46:20Z

This bug should be fixed upstream.
If your problem is still present then please open a new issue with details and traces.

leifj changed the title ~~T0/T1 mismatch~~ T0/T1 marshaling confusion Oct 17, 2016

leifj mentioned this issue Dec 1, 2016

tentative fix for direct access to 2wire readers #34

Closed

LudovicRousseau closed this as completed Jan 27, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

T0/T1 marshaling confusion #31

T0/T1 marshaling confusion #31

leifj commented Oct 17, 2016 •

edited

Loading

leifj commented Oct 18, 2016

LudovicRousseau commented Oct 18, 2016

LudovicRousseau commented Oct 18, 2016

leifj commented Oct 18, 2016 •

edited

Loading

leifj commented Oct 18, 2016 •

edited

Loading

leifj commented Oct 18, 2016

leifj commented Oct 18, 2016

LudovicRousseau commented Oct 21, 2016

leifj commented Oct 25, 2016

LudovicRousseau commented Oct 26, 2016

LudovicRousseau commented Nov 7, 2016

leifj commented Nov 7, 2016

leifj commented Nov 23, 2016

LudovicRousseau commented Dec 1, 2016

LudovicRousseau commented Jan 2, 2017

leifj commented Jan 2, 2017

LudovicRousseau commented Jan 5, 2017

leifj commented Jan 5, 2017 via email

LudovicRousseau commented Jan 6, 2017

LudovicRousseau commented Jan 27, 2017

T0/T1 marshaling confusion #31

T0/T1 marshaling confusion #31

Comments

leifj commented Oct 17, 2016 • edited Loading

leifj commented Oct 18, 2016

LudovicRousseau commented Oct 18, 2016

LudovicRousseau commented Oct 18, 2016

leifj commented Oct 18, 2016 • edited Loading

leifj commented Oct 18, 2016 • edited Loading

leifj commented Oct 18, 2016

leifj commented Oct 18, 2016

LudovicRousseau commented Oct 21, 2016

leifj commented Oct 25, 2016

LudovicRousseau commented Oct 26, 2016

LudovicRousseau commented Nov 7, 2016

leifj commented Nov 7, 2016

leifj commented Nov 23, 2016

LudovicRousseau commented Dec 1, 2016

LudovicRousseau commented Jan 2, 2017

leifj commented Jan 2, 2017

LudovicRousseau commented Jan 5, 2017

leifj commented Jan 5, 2017 via email

LudovicRousseau commented Jan 6, 2017

LudovicRousseau commented Jan 27, 2017

leifj commented Oct 17, 2016 •

edited

Loading

leifj commented Oct 18, 2016 •

edited

Loading

leifj commented Oct 18, 2016 •

edited

Loading