On 2012.08.18 00:03, David Grant wrote: > After looking at what VMWare View Client does, they seem to replace the > existing driver with their own generic USB driver called vmusb.sys after > the user decides to remote a particular USB device. Then after the user > decides to un-remote the device, or disconnects their session, it > switches the driver back to the appropriate driver (USB mass storage > driver for example). All without a reboot.
Yes switching drivers back and forth without a reboot and without user notification is doable. libwdi [1] can actually do that right now (if you embed the target driver you'll need to restore in the library as libwdi doesn't current support driver uninstallation/restore). Of course, the caveat is that you need an executable with administrative privileges running and unless you want to have people running around scared due to the silent installation of trusted certificates (and to all those people I'll point out once more that, as long as the chain of trust isn't broken, this behaviour is no less safe than WHQL), your driver package (inf) would have to have gone through WHQL... Of course, for a company like VMWare, installing a service with administrative privileges and getting vmusb.sys certified by Microsoft is not that big a deal. Then again, not everybody has the resources of VMWare. Thus, unless you manage to find a security hole in Windows, any non-obtrusive driver installation/replacement of a driver requires: - elevated privileges for the driver installer app - a 32 or 64 bit installer app depending on whether your system in 32 or 64 (Windows 64 cannot install a driver if that request comes from a 32 bit app) - either a WHQL driver or the silent installation of trusted certificates in the Windows cert store (for more on this, see [2]) if you want to avoid user prompts during install. In the later case, if you care about security, as you should, and you're not running a vetted application in a corporate environment, then the app should be signed to provide some form of accountability and user-trust. The certificate installed should also be the one autogenerated by libwdi, rather than one you would distribute, as it will otherwise introduce a major security risk for end users should your private key get stolen. > I wonder if libusbK.sys can > achieve do the same thing for us at runtime. Well, libwdi can already perform the first part of silently switching an existing USB driver to libusbK: you could create a service based on libwdi (with libusbK embedded in the library), and use the libwdi silent installation facilities to get the original driver silently replaced as needed. As libwdi disables the creation of a restore point by default when possible, this process shouldn't take that much longer than VMWare's driver switching. Now, due to time constraints as well as other considerations (removing/deleting anything needs to be carefully considered), libwdi doesn't support restoring the original driver, so unless you also embed the driver to restore in the library, you'll be missing the second part of a driver toggle. Hopefully, in the long run, this feature can be added to the library. It's also likely that VMWare use a trick for the driver disabling and restoration, as non WHQL drivers would produce a prompt on restore if using the standard Windows API for driver replacement, which I don't think their process does. But to answer your question, yes, libusbK.sys could achieve the same thing, and it can actually do it right now through libwdi, provided you know what driver you'll need to restore and if that driver is WHQL. All that's needed then is embeds both drivers in libwdi and create an app around it. Regards, /Pete [1] http://libwdi.akeo.ie [2] http://libwdi-cps.akeo.ie ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
