Have you ever attached your smartphone to your Windows computer and then looked at the phone in Windows Explorer? The phone gets listed in Explorer and you can even copy files to it (apple the exception). What makes the phone different from a regular storage device is that it does not get assigned a drive letter. Some of the older (1-2 years ago…smile) phones get assigned a drive letter but the newer phones being sold today do not get a drive letter.
The cool thing about Explorer is that in general, the end-users experience for working with either a drive letter or a storage device such as the phone are pretty much identical. You can drag (copy) files to these devices, open files, create folders, etc.
So what is happening under the covers to have Explorer be able to handle non-drive letter devices like drive letter devices? The answer is a Microsoft technology called Windows Portable Devices (WPD). WPD is implemented as a device driver and is exposed to the non-kernel (i.e. user-mode code) layer as COM objects. Microsoft makes WPD available to the hardware manufacturers who make the smartphones or any other type of plug and play hardware. The hardware manufacturers lean towards using WPD because then they do not have to develop their own software to integrate their hardware into Windows. Having worked with the WPD COM API, I will tell you that Microsoft has done a great job at implementing this technology. The only thing I could say that would make it even better is if it was exposed in WMI so IT Admins could have easy scripting access to the WPD information. So that is what we did. The Powershell line below will show you the WPD devices attached to a Windows computer:
At Squadra Technologies, we have a security product called secRMM that focuses on securing any type of plug-and-play storage device. That includes the new smartphone devices. Our goal was to make the WPD devices and the file system devices (i.e. those that get assigned a drive letter) the same within secRMM. Since secRMM needed to access the WPD information, we decided that we might as well write a WMI provider for the WPD information so that even if you did not use secRMM, you could still get at the WPD data. The WPD WMI provider gets installed with the secRMM product. Again, you do not need to buy secRMM to get the functionality of the WPD WMI provider.
If you do not write in Powershell, here is another example in VBScript:
Set objWMIService = GetObject (“winmgmts:\\.\root\cimv2″)
Set colItems = objWMIService.ExecQuery (“Select * from Win32ext_WPD”)
For Each objItem in colItems
Wscript.Echo “WPD device: ” & _
“Friendly Name: ” & objItem.strFriendlyName & _
“, Manufacturer: ” & objItem.strManufacturer & _
“, Description: ” & objItem.strDescription & _
“, Serial Number: ” & objItem.strSerialNumber
We will continue to work hard to stay on the leading edge of all the device technology coming into the market and share what we discover. We hope this introduction was informative. If you have any questions, please contact me at firstname.lastname@example.org.