CCID_Receive() Can't read all data 49xyzkbytes #66
Comments
vjardin
added a commit
to vjardin/CCID
that referenced
this issue
Mar 27, 2020
Currently, when some extended APDU are processed, we get the following
error:
CCID_Receive() Can't read all data 49174kbytes
In fact, the processing of the length of the APDU is not correct. For
example:
00000002 commands.c:1726:CmdXfrBlockAPDU_short() T=0: 9 bytes
00000003 -> 000000 6F 09 00 00 00 00 2D 00 00 00 00 A4 09 04 04 3F 00 D0 03
00033873 <- 000000 80 02 00 00 00 00 2D 00 00 00 61 27 00 00 00 00 00 00 00
[...]
00002330 commands.c:1682:CCID_Receive() Can't read all data (49174 out of 2 expected)
According to the log, the response should be correct but the reader may
add too many zeros to the response. The actual response APDU is 61 27.
If we check the complete logs/dumps, all the payload till the end is
full of 00 .. 00.
In fact, the check of the length of the data should be less strict.
Let's be tolerant as along as we get enough payload.
This fix has been tested with:
- Gemalto (was Gemplus) GemPC Twin
- Alcor Micro Corp. AU9540
- Feitian R502
Suggested-by: @godfreychung
Fix: issue LudovicRousseau#66
|
The discussion happens in the PR #67 |
vjardin
added a commit
to vjardin/CCID
that referenced
this issue
Aug 3, 2020
Currently, when some extended APDU are processed, we get the following
error:
CCID_Receive() Can't read all data 49174kbytes
In fact, the processing of the length of the APDU is not correct. For
example:
00000002 commands.c:1726:CmdXfrBlockAPDU_short() T=0: 9 bytes
00000003 -> 000000 6F 09 00 00 00 00 2D 00 00 00 00 A4 09 04 04 3F 00 D0 03
00033873 <- 000000 80 02 00 00 00 00 2D 00 00 00 61 27 00 00 00 00 00 00 00
[...]
00002330 commands.c:1682:CCID_Receive() Can't read all data (49174 out of 2 expected)
According to the log, the response should be correct but the reader may
add too many zeros to the response. The actual response APDU is 61 27.
If we check the complete logs/dumps, all the payload till the end is
full of 00 .. 00.
In fact, the check of the length of the data should be less strict.
Let's be tolerant as along as we get enough payload.
This fix has been tested with:
- Gemalto (was Gemplus) GemPC Twin
- Alcor Micro Corp. AU9540
- Feitian R502
Suggested-by: @godfreychung
Fix: issue LudovicRousseau#66
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Some PKCS11 smart cards return some trailing 00 so we get this error,
CCID_Receive() Can't read all data 49174kbytesthat lead to a failure of this test:
CCID/src/commands.c
Line 1573 in 745c4ef
if (length-10 != dw2i(cmd, 1))In fact, we should tolerate that the length is valid as long as we have enough payload, so it could become:
if (length-10 != dw2i(cmd, 1))Without this patch, the following reader could not support some PKCS11 smart cards:
Once it gets applied, they work fine.
The same fix was validated on some ACR with their CCID:
acshk/acsccid@e23befb
The text was updated successfully, but these errors were encountered: