Windows Smart Card Subsystem and Remote Sessions

Situation

1. When you have an eToken usb device which is connected to a PC somewhere in your home or office and you want to use this token via a remote session. For instance. you're in another city with your favourite notebook. You use built-in Windows Remote Desktop  Connection to access some applications required the usb token. Here we have an RDP session.

2. At work you have a VMware View infrastructure that uses PCoIP protocol. You added a usb passthrough device to a specific virtual machine. It means that your token connected directly  to the ESXi host. This is the only possible way to make a token visible in a virtual machine that I know (directly connected tokens on the client side doesn't work in PCoIP). Then a user opens VMware View client and wants to access the token through some special applications.

Problem

Microsoft Smart Card subsystem blocks access to any locally attached usb tokens or smart card readers in a remote session. Theoretically, you should attach required devices on the client side, but it's not cool and often is not acceptable. I've seen this problem using such protocols as RDP or PCoIP (let's call them session protocols), whereas everything works fine via VNC or Radmin, because these products use their own methods to connect directly to the local session of PC or virtual machine.

Solving

I tried to find an answer in the Internet fields. I looked through many forums finding any helpful information. So, I decided to solve the issue by my own.

First thing that I did was to emulate the situation. I took a usb eToken and attached it to a virtual machine on VMware ESXi host. After that, I had to add one usb controller and my usb device to the VM in vCenter. Next, I opened view client and connected to my vm. I used eTokens by Aladdin-rd. There are special drivers for eTokens - PKI client 5.1 SP 1. It can be downloaded from the official site.

After we have the token and required drivers, it's possible to test the issue. If open eToken Prperties in local session and go to Managing Readers, we'll see this:

But if we do it in a remote session, we'll get 0 readers instead of 2, because eToken service couldn't get any information from a Windows smart card subsystem. Let's have a look on a smart card architecture in Windows:

It is logical that the problem is somewhere in the core of the architecture, somewhere in WinSCard.dll. But let's begin from the top of the iceberg. eToken Properties is an application included in driver pack eToken PKI Client. We should have a look at an import section:

That's it. The most interesting and valuable in etProps.exe's import section are these functions from WinSCard.dll. After a quick view in MSDN, it's easy to find a necessary function: SCardEstablishContext. There is also a valuable remark to this function:

"If the client attempts a smart card operation in a remote session, such as a client session running on a terminal server, and the operating system in use does not support smart card redirection, this function returns ERROR_BROKEN_PIPE."

Good. Now, we know that it is the function that should be debuged. I prefer to use WinDbg from Debugging Tools. I debuged this function in remote and local sessions and got the next result. Function SCardEstablishContext calls internal InTSMethodWithContext that then also calls undocumented WinStationIsSessionRemoteable from winsta.dll which checks if we work in local or remote session. It's a bad idea to modify winsta.dll - for some programs it's useful to know the real type of session. So, lets patch WinSCard.dll. Function InTSMethodWithContext returns 1 if we work in remote session and 0 if in local. I decided to put "xor eax, eax" in the end of function instead of coping the real value of out WinStationIsSessionRemoteable argument.

Then in hex editor I replaced "0F B6 45 FF" to "33 C0 90 90" with 1C40 offset. Almost done. Finally, the original Windows system file C:\Windows\System32\WinSCard.dll should be replaced by patched and that's it.

After these manipulations I've got a workable Windows Smart Card subsystem and any eTokens work well as in a local session as in a remote one via RDP or PCoIP.

UPD: Don't forget about Windows File Protection mechanisms in Windows. You should turn if off or replace a required file in cache as well. Otherwise, our modified file will be replaced by the original in a background.

UPD: Here is a patch. I tested it only with XP ProSP3/32, However, it should work with 7 Pro/32 too.

UPD: The last version of the path is available at lifayk.com. Here is a direct link: http://lifayk.com/files/scpatch0.3.zip