TCP network trace raises questions
Closed this issue · 2 comments
Capturing packets between Android Smart Card reader app and the VPCD driver running on Windows 11, I noticed some traffic that raised questions. Here is the first few packets of traffic. The data is listed in numbered sequence where > indicates an outbound packet from VPCD to reader and < indicates an inbound packet from reader to VPCD;
01 >00 01 04
02 <00 0F 3B 8A 80 01 00 31 C1 73 C8 40 00 00 90 00 90
03 >00 01 04
04 <00 0F 3B 8A 80 01 00 31 C1 73 C8 40 00 00 90 00 90
05 >00 01 02 00 01 04
06 <00 0F 3B 8A 80 01 00 31 C1 73 C8 40 00 00 90 00 90
07 >00 01 02 00 01 04
08 <00 0F 3B 8A 80 01 00 31 C1 73 C8 40 00 00 90 00 90
09 >00 01 04
10 <00 0F 3B 8A 80 01 00 31 C1 73 C8 40 00 00 90 00 90
11 >00 01 02 00 01 04
12 <00 0F 3B 8A 80 01 00 31 C1 73 C8 40 00 00 90 00 90
13 >00 10 00 A4 04 00 0B A0 00 00 03 97 43 49 44 5F 01 00
14 <00 02 6A 82
I am noticing two things;
- The request for ATR is repeated a total of 6 times before the first APDU is actually sent from the Windows OS after card inserted has been asserted by VPCD
- The request for ATR appears malformed in packets 05, 07 and 11. Specifically the 16 bit length indicates 1 byte but 4 bytes are sent.
My questions are;
- Is the constant querying for ATR from VPCD designed as a form of no-op or keep-alive check of the TCP connection's status?
- Are packets 05, 07, and 11 indeed malformed ATR requests which remote-reader on Android is truncating to the last byte "04" due to the preceding specified length indicating a single byte, and serendipitously still interpreting as an ATR request?
@mildsunrise this is data captured from virtualsmartcard release version 0.8 (prior to your recent contribution). Considering your changes to calculating and sending the length (size) bytes and payload in a single call to sendall(), do you think this may have inadvertently solved this problem? I have no tools nor skill enough to compile and test or I would :/
Oh wow.. when I said I didn't have the skill, I was dead on.
This is not an issue. There are simply two separate control codes sent;
00 01 02 - reset, which generates no response from the remote reader
00 01 04 - get atr
Sorry. I wish github allowed reverting back the complete history of the universe to pretend like I never posted this issue.