When I insert a Smart Card to the reader after receiving ATR I can see in the driver log a number of IOCTL's that are not sent by my application (as is not running).
My question is if there is any document, describing Smard Card communication establishment in windows?
There is the Win32 API for communicating with smart cards within Windows
platform in form SCardXXX. Similar implementation for Linux is developed under
Muscle project as PC/SC Lite API.On Windows platform Following functions will be used:
SCardEstablishContext
SCardListReaders
SCardConnect
SCardReconnect
SCardDisconnect
SCardReleaseContext
SCardTransmit
Figure shows that how the smart card intract with application on windows platform.
For more information see the Here
Related
I have a web app which uses web bluetooth api. GATT server is running on STM32 microcontroller. Web app works good on Android devices, but it keeps disconnecting on Windows 11 in a Chrome browser. I used WireShark to track BLE packets. The disconnection reason is following: "Remote user terminated connection (0x13)".
I have tested web bluetooth on the same windows device with a different GATT server running on my Android phone. In this case it worked well. What can be an issue?
The peripheral is sending a malformed GATT packet.
Packet 163, Read By Group Response, contains 156 bytes of Attribute Protocol data. It contains a list of services, each is 20 bytes, consisting of (start handle, end handle, service uuid). The list contains 7 valid entries. After that follows an entry which is truncated to 14 bytes. That entry should not be present in the list since it does not fit. So, it seems the GATT server software running on the peripheral is buggy.
The client is supposed to continue the search by sending a new Read By Group Request containing a start handle that is +1 of the last retrieved end handle.
I am trying to talk to a MSC USB device (interface class 8, subclass 6, protocol 0x50) via a plain USB API with endpoints (all set up for me).
Provided I have a valid CDB, such as for "Test Unit Ready", how to I send that over the USB interface?
Where can I find examples or docs for how this is done?
Background: The actual platform is macOS, which doesn't provide SCSI-passthrough for block devices, and the native SCSI API is also not available in this case.
I have, however, been able to initiate communication on the USB level with the device, and am now trying to circumvent the blocked SCSI device level access by talking thru USB directly.
Most such devices implement the so-called “Bulk Only” protocol, which is specified here: https://usb.org/document-library/mass-storage-bulk-only-10
Essentially, you send a 31-byte “Command Block Wrapper”, which includes the CDB and is specified in section 5.1 of the spec, to the device via the bulk out endpoint. You then read or write the data to be transferred from the input bulk endpoint or to the output bulk endpoint and finally read the 13-byte command status wrapper from the bulk in pipe.
However, note that you’ll need to make sure the OS hasn’t already loaded a driver for the device - from user space, the system won’t give you access to the endpoints when a kernel driver has claimed them anyway, but if you were to attempt to use the same pipes as the default driver from a kext, you’d get unpredictable results.
I am looking at implementing USB communication on a MCU which has a USB engine built into it. Basically you have access to the pipes/endpoints.
I am a little bit confused on the USB stack now. It appears that drivers operate on another level above the pipe/endpoint setup, so the pipe/endpoint is like a middle level layer that drivers are built on. Is this correct?
Secondly, I am interested in simulating serial communication over USB. It appears windows has a premade driver so on the computer side I do not need to program the pipe level.
How do I find out what I need to implement on the MCU to make it behave correctly with the generic serial driver?
This is an answer to your second question regarding the serial communication.
The USB standard defines a communication device class (CDC) for serial communication. The required drivers on the host side are implemented by Windows, macOS, Linux and many more operation systems.
The relevant CDC subclass is PSTN. The relevant documents are found in Class definition for Communication Devices 1.2.
The device basically implements four endpoints:
Control endpoint for configuration requests (baud rate, DTR state etc.). Have a look at SetLineCodeing, GetLineCoding and SetControlLineState.
Bulk endpoint for USB to serial transmission
Bulk endpoint for serial to USB transmission
Interrupt endpoint for notifications (DCD state, errors). See SerialState.
And of course you need to get the device descriptor right.
On top of that, you need to implement all the standard USB requests.
Chances are high that this has already been written for your MCU, both the standard requests and the serial communication. So why not use the existing code?
I am developing a Win32 application for a Windows 10 tablet that shall connect to a embedded device via Bluetooth. The embedded device uses the Telit BlueMod+SR as bluetooth module.
In Windows, I use the interface from "bluetoothapis.h" for Connection and Pairing and winsock2 for communication.
I have to implement pairing using passkey entry between the devices, initiated by the Windows tablet. The tablet provides passkey entry, the embedded device is display-only.
The way it works at the moment is that:
Windows creats a non-blocking socket and configures it as requiring authentication by setting SO_BTH_AUTHENTICATE.
Windows passes my Authentication Callback to BluetoothRegisterForAuthenticationEx().
Windows calls ConnectEx() on the remote BT device.
If successful, the Authentication Callback is executed, giving me the passkey (which is displayed by the embedded device).
The user is asked to input the passkey on the tablet which then compares the input with the passkey from the Authentication callback.
My problem is, although it works, I think that this is not the way the passkey entry is intended. It doesn't feel like a valid way to establish a secure connection since the embedded device seems to transmit the passkey via Bluetooth to the tablet.
Should the passkey be openly transmitted via Bluetooth from the remote device to the initiating device?
Or should the user be the only one that gives the passkey to the tablet?
If the way it is implemented is wrong:
Does somebody have an idea why the passkey is available through the Authentication Callback on Windows? I guess there is something wrong with the configuration of the BlueMod module, but I haven't been able to change the behavior.
Im having a problem with switching a Mifare Plus SE from SL1 to SL3, using acs acr122U with pn532
In SL1 the card is detected as a Mifare Classic (Same ATR) and to perform the switch i need to activate the comunication in 14443-4 and do the auth command with the SL3 switch key. I trying to activate the comunication in 14443-4, but im not finding how.
In other card which its already in SL3 (Also on SL1) the card is activated without problems in 14443-4 and i can send the mifare plus operations without problems.
Im using Smartcardio and transmitcontrolcommand to send the commands to the acr122U trying to use these commands from the PN532 :
-inAutoPoll (Which detects the card as 10 (mifare card, not 14443-4 card)
-InListPassiveTarget (Actives the card as mifare classic too)
-inATR (Which ends with a timeout)
I tryed to inRelease and reactivate again, is not working neither.
Thanks for your time
The problem you are facing is MFP in SL1 acts as a MFC, and does not advertise support for 14443-4 in its SAK. Most high-level libraries will simply not try to send RATS to switch to -4.
For MFP authentication command to work on 0x9001 (prerequisite for switching to SL3), you actually have to be in -4 mode, so you'll have to force sending RATS to get to -4, even if not advertised by card. Depending on your NFC library's API, this may not be possible.
For implementation in backend-agnostic code, I ended-up reimplementing -4 framing and using low-level communication APIs just for this case.
Once in SL3, -4 support is advertised, and switching happens transparently in most communication libraries.