I'm in the middle of converting some older code to talk with a custom SCSI device. The original code was written for WinXP and ASPI, and the newer code needs to work on Win7 and SPTI. My problem is that the newer code fails on a call to do a SCSI "Mode Select" operation with an status code of 2, which is a SCSI "Check Condition" error - but this doesn't happen with the older code under WinXP.
Normally, when you get a "Check Condition" code, you can issue a "Request Sense" command to the device to find out what happened. Unfortunately, this device is (in my opinion) buggy, and always returns "everything is okay" when you do a Request Sense. So I'm working in the dark here.
So I'm hoping for some suggestions on what I could be doing wrong with the SPTI code, and would be grateful for any feedback.
Here are a few things I've thought of that may be affecting this:
The sequence the device expects is "Reserve Unit", "Rezero Unit", "Mode Select", then some other operations, then "Release Unit". It appears "Reserve Unit", "Rezero Unit", and "Release Unit are all working fine, but the other operations fail because "Mode Select" failed.
For each operation, the SPTI code opens and closes a handle to the SCSI host adapter. Should I open a handle in "Reserve Unit" and leave it open for the entire sequence?
The ioctl sent to DeviceIoControl() is IOCTL_SCSI_PASS_THROUGH. Should I be using IOCTL_SCSI_PASS_THROUGH_DIRECT for the "Mode Select" operation? It's a simple operation, so I figured the simpler API would be adequate for this, but maybe I'm wrong about that.
The code in question is:
void MSSModeSelect(const ModeSelectRequestPacket& inRequest, StatusResponsePacket& outResponse)
{
IPC_LOG("MSSModeSelect(): PathID=%d, TargetID=%d, LUN=%d", inRequest.m_Device.m_PathId,
inRequest.m_Device.m_TargetId, inRequest.m_Device.m_Lun);
int adapterIndex = inRequest.m_Device.m_PathId;
HANDLE adapterHandle = prvOpenScsiAdapter(inRequest.m_Device.m_PathId);
if (adapterHandle == INVALID_HANDLE_VALUE)
{
outResponse.m_Status = eScsiAdapterErr;
return;
}
SCSI_PASS_THROUGH_WITH_BUFFERS sptwb;
memset(&sptwb, 0, sizeof(sptwb));
#define MODESELECT_BUF_SIZE 32
sptwb.spt.Length = sizeof(SCSI_PASS_THROUGH);
sptwb.spt.PathId = inRequest.m_Device.m_PathId;
sptwb.spt.TargetId = inRequest.m_Device.m_TargetId;
sptwb.spt.Lun = inRequest.m_Device.m_Lun;
sptwb.spt.CdbLength = CDB6GENERIC_LENGTH;
sptwb.spt.SenseInfoLength = 0;
sptwb.spt.DataIn = SCSI_IOCTL_DATA_IN;
sptwb.spt.DataTransferLength = MODESELECT_BUF_SIZE;
sptwb.spt.TimeOutValue = 2;
sptwb.spt.DataBufferOffset =
offsetof(SCSI_PASS_THROUGH_WITH_BUFFERS,ucDataBuf);
sptwb.spt.Cdb[0] = SCSIOP_MODE_SELECT;
sptwb.spt.Cdb[4] = MODESELECT_BUF_SIZE;
DWORD length = offsetof(SCSI_PASS_THROUGH_WITH_BUFFERS,ucDataBuf) +
sptwb.spt.DataTransferLength;
memset(sptwb.ucDataBuf, 0, sizeof(sptwb.ucDataBuf));
sptwb.ucDataBuf[2] = 0x10;
sptwb.ucDataBuf[4] = 0x01;
sptwb.ucDataBuf[5] = 0x04;
ULONG bytesReturned = 0;
BOOL okay = DeviceIoControl(adapterHandle,
IOCTL_SCSI_PASS_THROUGH,
&sptwb,
sizeof(SCSI_PASS_THROUGH),
&sptwb,
length,
&bytesReturned,
FALSE);
DWORD gle = GetLastError();
IPC_LOG(" DeviceIoControl() %s", okay ? "worked" : "failed");
if (okay)
{
outResponse.m_Status = (sptwb.spt.ScsiStatus == 0) ? eOk : ePrinterStatusErr;
}
else
{
outResponse.m_Status = eScsiPermissionsErr;
}
CloseHandle(adapterHandle);
}
The solution proved to have two parts.
First, sptwb.spt.DataIn needed to be SCSI_IOCTL_DATA_OUT rather than SCSI_IOCTL_DATA_IN - because, of course, "Mode Select" is telling the device what to do, rather than asking it for information. This changed the result of DeviceIoControl() from TRUE to FALSE, and GetLastError() then returned a value of 87, indicating an invalid parameter.
Second, as I'd speculated, the ioctl transaction needs to be done using IOCTL_SCSI_PASS_THROUGH_DIRECT rather than IOCTL_SCSI_PASS_THROUGH.
Once everything was set up right with those two changes, the "Mode Select" command succeeded.
Related
The 2 trojans:
Wacatac.G!ml
Persistence.G!ml
Here's the code that I believe is causing the issue. The purpose is to create/modify a registry key to make the program run on startup:
void SoftwareDlg::SetSURegValue() {
string regSubKey("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\\");
string regValueName = "Software";
string regValue = "D:\\Users\\Skew\\Documents\\repos\\Software\\Debug\\Software.exe"
try
{
size_t bufferSize = 0xFFF;
auto cbData = static_cast<DWORD>(regValue.size() * sizeof(char));
HKEY hKey;
DWORD position;
auto rc = RegCreateKeyEx(HKEY_CURRENT_USER, regSubKey.c_str(), 0, NULL, REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, &hKey, &position);
if (position == REG_OPENED_EXISTING_KEY) {
DEBUG_PRINT("Key already exists & has been opened.")
}
else if (position == REG_CREATED_NEW_KEY) {
DEBUG_PRINT("Created new key.")
}
else {
DEBUG_PRINT("ERROR: Key does not exist, and a new key was not created.")
}
if (rc == ERROR_SUCCESS) {
auto rc = RegSetValueEx(hKey, regValueName.c_str(), 0, REG_SZ, (BYTE*)regValue.data(), cbData);
if (rc != ERROR_SUCCESS)
{
throw std::runtime_error("Windows system error code: " + to_string(rc));
}
}
else {
DEBUG_PRINT("Error opening key.\n")
}
}
catch (std::exception& e)
{
DEBUG_PRINT(e.what())
}
}
In my attempts to solve this issue I began testing different scenarios of creating/modifying the key, but my results became inconclusive when I realized that Windows Defender had seemingly stopped logging each run as "new threats" and seemed to log them together as a single "permeant threat" I guess? Not really sure.
With that said, Windows Defender did not seem to log the threat when I would initially create the key or when I would open it and assign it the same value, but did appear to log the threat when I would move the program to a new directory(and the program would attempt to change the value of the "Software" registry value to the new EXE location).
That's left me with several questions:
Does my program mimic the behavior of the 2 trojans through some coding mistake?
Or do I have some latent, opportunistic piece of malware on my machine that's just been waiting to take advantage?
Is deleting the existing value necessary before attempting to change it? The behavior of RegCreateKeyEx leads me to believe this is not the case.
Is writing to the registry without elevated permissions a no-no? If so... why does my machine let me do it?
Am I doing some incorrect type conversion in the RegSetValueEx() function?
If #4 is the case, I guess I'm just really surprised that I was notified by Windows Defender and not Visual Studio or a UAC prompt.
Edit 1: No engines on VirusTotal.com detected the file as malware.
Please can anyone give me direct for realization next functional for Windows.
I have USB device which connects to the PC (it is JTAG programmer.) I know VID and PID of this hardware. I need:
1 Check what type of driver this hardware use (detecting winusb driver or not will be enough. Maybe do I need to read registry?)
2 If driver is not winusb I need to install winusb driver for this USB device from my application.
The current driver assigned to the device is stored in the registry, so you could read it directly from there. However, it is probably better to use SetupAPI, an API provided by Microsoft. The function to call is SetupDiGetDeviceRegistryProperty, and the third argument should be SPDRP_SERVICE. This will return the name of the driver as a string. Note that you will need to call several other SetupAPI functions before you have all the pieces of info you need to call SetupDiGetDeviceRegistryProperty.
I have not tried it, but libwdi has features for installing WinUSB onto a device node. It might also have functions for getting the current driver, so you should try using it before you spend too much time learning SetupAPI. The devcon utility from Microsoft (which is open source now) might be another option.
Without knowing the details of what you are doing, I question whether you really need to do this. It might be simpler to provide a signed driver package to users and instruct them to use the "Update Driver Software..." option from the Device Manager to apply it to particular device.
I made first part of task.
#ifdef Q_OS_WIN
DEFINE_GUID(GUID_DEVCLASS_WINUSB,0x88BAE032,0x5A81,0x49f0,
0xBC,0x3D,0xA4,0xFF,0x13,0x82,0x16,0xD6);
#endif
bool WinUSB::isWinUsbDriver(quint16 vid, quint16 pid)
{
#ifndef Q_OS_WIN
Q_UNUSED(vid);
Q_UNUSED(pid);
return true;
#else
HDEVINFO deviceInfoSet;
GUID *guidDev = (GUID*) &GUID_DEVCLASS_WINUSB;
deviceInfoSet = SetupDiGetClassDevs(guidDev, NULL, NULL, DIGCF_PRESENT | DIGCF_PROFILE);
DWORD buffersize =4000;
TCHAR buffer [buffersize];
int memberIndex = 0;
bool retval = false;
QString vidPid;
vidPid = "VID_" + QString("%1").arg(vid,4,16,QChar('0')) + "&";
vidPid += "PID_" + QString("%1").arg(pid,4,16,QChar('0'));
while (true)
{
SP_DEVINFO_DATA deviceInfoData;
ZeroMemory(&deviceInfoData, sizeof(SP_DEVINFO_DATA));
deviceInfoData.cbSize = sizeof(SP_DEVINFO_DATA);
if (SetupDiEnumDeviceInfo(deviceInfoSet, memberIndex, &deviceInfoData) == FALSE) {
if (GetLastError() == ERROR_NO_MORE_ITEMS) {
break;
}
}
DWORD nSize=0 ;
SetupDiGetDeviceInstanceId (deviceInfoSet, &deviceInfoData, buffer, sizeof(buffer), &nSize);
buffer [nSize] ='\0';
QString str = QString::fromWCharArray(buffer);
if (str.indexOf(vidPid) >= 0) {
retval = true;
break;
}
memberIndex++;
}
if (deviceInfoSet) {
SetupDiDestroyDeviceInfoList(deviceInfoSet);
}
return retval;
#endif
}
Edit:
The answer of this question is here:
https://stackoverflow.com/a/27317947/996540
When you create a project in msvc, the option /DYNAMICBASE is default enabled
now. Because of ASLR(Address space layout randomization, since Windows Vista),
everytime you run an exe, it's load address is random.
I am doing the DLL injection job recently, so I did some research into it on
google, and have read some projects. Get the load address (base address) of an
exe is important.
It seems there're two simple APIs to do this: EnumProcessModulesEx and
CreateToolhelp32Snapshot. But I never succeeded.
So this is the code sample:
void TestEnumProcessModulesEx(const char* app)
{
std::cout << "Begin TestEnumProcessModulesEx(" << mybit() << ")" << std::endl;
STARTUPINFOA startupInfo = {0};
startupInfo.cb = sizeof(startupInfo);
PROCESS_INFORMATION processInformation = {0};
if (CreateProcessA(app, NULL, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &startupInfo, &processInformation))
{
std::vector<HMODULE> buf(128);
DWORD needed = 0;
for (;;) {
if (EnumProcessModulesEx(processInformation.hProcess, &buf[0], DWORD(buf.size()*sizeof(HMODULE)), &needed, LIST_MODULES_ALL) == FALSE) {
DWORD ec = GetLastError();
std::cout << "GetLastError() = " << ec << std::endl;
break;
}
else if (needed <= buf.size() * sizeof(HMODULE)) {
break;
}
else {
const size_t oldSize = buf.size();
buf.resize(oldSize * 2);
}
}
ResumeThread(processInformation.hThread);
WaitForSingleObject(processInformation.hProcess, INFINITE);
}
std::cout << "End TestEnumProcessModulesEx(" << mybit() << ")" << std::endl;
}
To reduce the length of this Question, the complete code - including the
CreateToolhelp32Snapshot's test code - is not listed here, but you can get it
from:
https://dl.dropboxusercontent.com/u/235920/enum_proc_mods_sample.7z
or
https://www.mediafire.com/?cry3pnra8392099
"If this function is called from a 32-bit application running on WOW64, it can
only enumerate the modules of a 32-bit process. If the process is a 64-bit
process, this function fails and the last error code is ERROR_PARTIAL_COPY
(299)." - from MSDN.
And this is a blog post about this question:
http://winprogger.com/getmodulefilenameex-enumprocessmodulesex-failures-in-wow64/
Unfortunately, this does not make sence, because whatever the specified
process is 32bit or 64bit, it fails with 299; whatever the caller process is
32-bit or 64bit, it fails with 299.
This is the output of my sample:
Begin TestEnumProcessModulesEx(32bit)
GetLastError() = 299
hello world 32bit
End TestEnumProcessModulesEx(32bit)
Begin TestEnumProcessModulesEx(32bit)
GetLastError() = 299
hello world 64bit
End TestEnumProcessModulesEx(32bit)
Begin TestEnumProcessModulesEx(64bit)
GetLastError() = 299
hello world 32bit
End TestEnumProcessModulesEx(64bit)
Begin TestEnumProcessModulesEx(64bit)
GetLastError() = 299
hello world 64bit
End TestEnumProcessModulesEx(64bit)
As you see, any combination is failed.
My OS is Windows 7 64bit pro and my compiler is VS2013.
So, what can I do ?
I have no idea about the unsuccess of EnumProcessModulesEx and
CreateToolhelp32Snapshot, let's leave this question to the expert.
My goal is to get the load address (base address) of the child process, find
the entry point and patch it - the reason to patch the entry point is here:
https://opcode0x90.wordpress.com/2011/01/15/injecting-dll-into-process-on-load/
Since DLL injection is the main purpose of mine, I have to reconsider this
question. I would use the "CreateRemoteThread & LoadLibrary Technique"
http://www.codeproject.com/Articles/4610/Three-Ways-to-Inject-Your-Code-into-Another-Proces#section_2
to do the DLL injection (In fact ASLR is not the barrier of this technique by the way),
Although there are so many limits in DLLMain
http://msdn.microsoft.com/en-us/library/windows/desktop/dn633971%28v=vs.85%29.aspx
, but do a little works is OK: Find the base address of an exe using
GetModuleHandleA(NULL), save the HMODULE returned into shared memory,
next, the caller process read shared memory and get the HMODULE.
Synchronization mechanism is necessary of course.
So, the answer is IPC. (not every IPC mechanism is safe in DLLMain by the way)
I'm using GetRawInputDeviceInfo to get the device name of a USB HID device name.
For some reason, when I run my code under Windows XP I get a device name which starts with \??\ and not \\?\.
This of course means, that when I try to use this device name (in CreateFile for example" it does not work. If I edit the device name and manually fix it to be \\?\ everything works great.
This does not happens in Windows 7. In Win7 everything works great.
I also test for GetLastError after every API call and no errors occur.
All my OS's are 32 bit and my project is compiling with unicode.
Any suggestions what am I doing wrong?? Here's a code snippets from my console application which gets the device name.
nResult = GetRawInputDeviceInfo( pDeviceList[i].hDevice, RIDI_DEVICENAME, NULL, &nBufferSize );
if( nResult < 0 )
{
cout << "ERR: Unable to get Device Name character count.." << endl;
return false;
}
WCHAR* wcDeviceName = new WCHAR[ nBufferSize + 1 ];
if( wcDeviceName == NULL )
{
cout << "ERR: Unable to allocate memory for Device Name.." << endl;
return false;
}
nResult = GetRawInputDeviceInfo( pDeviceList[i].hDevice, RIDI_DEVICENAME, wcDeviceName, &nBufferSize );
if( nResult < 0 )
{
cout << "ERR: Unable to get Device Name.." << endl;
delete [] wcDeviceName;
return false;
}
wcDeviceName[1]='\\';
//This is the manual fix for the device name in WinXP. How do I get rid of it????
pDesc->hHandle = CreateFile(wcDeviceName, GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_EXISTING, NULL, NULL);
...
...
You are not doing anything wrong.
Just change the second character to \ and you are set. What you see is the raw device path in its native form (\??\...). When you have the form \\?\ that is a crutch MS invented to make long path names available on Win32 when NT arrived despite the limitation of the Win32 subsystem to the \?? object directory.
Please read a few of the chapters of "Windows Internals" by Russinovich (any old edition will do) and use winobj.exe from Sysinternals to explore the object namespace of Windows to see what I'm talking about.
Side-note: when you call CreateFile the code in kernel32.dll will literally undo the suggested change and convert it back to its native form before the native functions get to see the path. So all you are doing with this is to make the Win32 layer understand the path.
How do I get from a drive letter to a device instance ID?
My process starts with a device arrival message. I have been successful in getting the drive letter from the arrival message and in opening the dvd tray.
I have searched the various Setup API items; but I haven't found anything that gets me from a drive letter to a device instance ID.
A solution in C# or VB.NET would be ideal, but I'm willing to figure it out from any other language as long as I can see the API calls.
Thanks in advance...
You cannot do it directly.
The link is to use STORAGE_DEVICE_NUMBER. You can use DeviceIoControl with IOCTL_STORAGE_GET_DEVICE_NUMBER on your device name to populate this structure. Put this value to one side.
You then need to get device infomation on your system using SetupDiGetClassDevs setting the GUIDS as approriate, indicicating the drives your are insterested in. Then enumerate through the devices using SetupDiEnumDeviceInfo. Then enumerate the interfaces using SetupDiEnumDeviceInterfaces and finally get the information using SetupDiGetDeviceInterfaceDetail. In this structure returned you can get a DevicePath you can use to get the STORAGE_DEVICE_NUMBER as above. Match this with the STORAGE_DEVICE_NUMBER from your drive letter, and you have now linked a driver letter to your structure. Phew! Inside this structure is a DevInst.
i know it's late for you now but not for everybody ^^
I had the same need and this is main line of how I did it:
-You need a window to receive device arrival and removal (as you said)
-Then you create a DeviceNotificationFilter initiated to dbcc_devicetype = DBT_DEVTYP_DEVICEINTERFACE
-Then in the message loop of your window you look for VM_DEVICECHANGE
-When u receive it if wParam == DBT_DEVICEARRIVAL, use the lParam to check if it is a DBT_DEVTYPE_VOLUME (i was getting the letter and the type of the drive here) or a DBT_DEVTYPE_DEVICEINTERFACE ( there you can use your wellcasted lParam to get the InstanceId from the input structure).
When you connect a drive your receive DEVINTERFACE first then the other.
I only give the main line beacause i did this long time ago and i don't have the code here, and also I had found a lot of code pieces on the net (long time ago so there should be more now ^^^) maybe msdn give a full code example to do that now.
If you read this and need more informations, i'll reply or make a full documented answer if many need it.
Hope it will help some of you.
I know it's years later but I had to do this and searching brought me here and #DanDan 's answer worked. In order to save future people a lot of work, I thought I'd give back a little and present the technique a bit more explicitly. You'll still have to write a bit of code, but the part I found difficult is below as code:
As DanDan mentioned, the idea is to use CreateFile and DeviceIoControl to get the Windows STORAGE_DEVICE_NUMBER for the disk associated with a file path, and then use the Setup API to enumerate disk devices until we find one whose device instance equals the SDN.
First, here's a summary of how you get the STORAGE_DEVICE_NUMBER from the path (e.g. c:\\users\\bob);
Strip the path to the root (e.g down to C:) and prepend it with \\\\.\\ so you have \\\\.\\C:
Open that path up using CreateFileW with to get metadata
Use DeviceIoControl with IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS to get the extents
Get the DiskNumber member from the first extent returned.
Close the file
Open up \\\\.\\PhysicalDrive<n> where <n> is the that DiskNumber from the first extent
Use DeviceIoControl with code IOCTL_STORAGE_GET_DEVICE_NUMBER to get make it fill out a STORAGE_DEVICE_NUMBER struct as output
Use SetupDiGetClassDevs with arguments &GUID_DEVCLASS_DISKDRIVE and DICGF_PRESENT to get all disks on the system
In a loop, use SetupDiEnumDeviceInfo to get a SP_DEVINFO_DATA repeatedly (on the device list returned by step #8 above) and a call the function below to determine which one, if any, matches the STORAGE_DEVICE_NUMBER for the give path.
(This is edited to remove custom utility classes of mine right on the SO web page so I might have introduced errors/typos)
bool DoesDeviceInstanceEqualStorageDeviceNumber(
const std::string& devInstance,
STORAGE_DEVICE_NUMBER sdn)
{
// Open up this device instance, specifying that we want the *interfaces*.
// The interfaces are key key because examining them will let us get a
// string we can use the Win32 CreateFile function.
const auto hDevInfo = SetupDiGetClassDevsA(
nullptr,
devInstance.c_str(),
nullptr,
DIGCF_DEVICEINTERFACE | DIGCF_ALLCLASSES);
if (hDevInfo == INVALID_HANDLE_VALUE)
throws std::runtime_error("Unable to get disk devices");
DWORD dwSize = 0;
SP_DEVINFO_DATA did;
WCHAR buffer[4096];
did.cbSize = sizeof (did);
bool foundValidMatch = false;
int deviceNumber = 0;
// Iterate through all such devices, looking for one that has a storage device number that matches the given one.
while ( !foundValidMatch && SetupDiEnumDeviceInfo(hDevInfo, deviceNumber, &did))
{
deviceNumber++;
DEVPROPTYPE devPropType;
// We'll only bother comparing this one if it is fixed. Determine that.
const auto getPropResult = SetupDiGetDevicePropertyW (
hDevInfo,
&did,
&DEVPKEY_Device_RemovalPolicy, // Ask for the "removal policy"
&devPropType,
(BYTE*)buffer,
sizeof(buffer),
&dwSize,
0);
if (!getPropResult)
{
std::cerr << "Unable to to get removal policy for disk device: " << ::GetLastError() << std::endl;
continue;
}
/* This bit *would* skip removable disks, you wanted...
else if (buffer[0] != 1)
{
std::cerr << "Skipping removable disk device " << devInstance << std::endl;
continue;
}
*/
// OK this is a fixed disk so it might be the one we'll compare against
// 1. Get the very first disk interface from this particular disk device
// 2. Open a file on it
// 3. Query the resulting file for its device number.
// 4. Compare the device number to the one we determined above
// 5. If it matches ours, then we succeed. If not, continue
SP_DEVICE_INTERFACE_DATA devIntData;
devIntData.cbSize = sizeof(SP_DEVICE_INTERFACE_DATA);
// Get the disk interfaces
const auto result = SetupDiEnumDeviceInterfaces(
hDevInfo,
&did, //&did,
&GUID_DEVINTERFACE_DISK, // Get Disk Device Interface (from winioctl.h)
0, // We only need the very FIRST one. I think...
&devIntData);
if (!result)
continue;
DWORD dwRequiredSize = 0;
// Want to get the detail but don't yet know how much space we'll need
// Do a dummy call to find out
SetupDiGetDeviceInterfaceDetail(
hDevInfo,
&devIntData,
nullptr,
0,
&dwRequiredSize,
nullptr);
if (ERROR_INSUFFICIENT_BUFFER != ::GetLastError())
{
std::cerr << "Unable to get device interface Detail: " << ::GetLastError() << std::endl;;
}
else
{
// Get the detail data so we can get the device path and open a file.
std::vector<TCHAR> buf(dwRequiredSize);
auto pDidd = reinterpret_cast<PSP_DEVICE_INTERFACE_DETAIL_DATA>(buf.data());
// WARNING: HARD CODED HACK
// ------------------------
// https://stackoverflow.com/questions/10405193/vb-net-hid-setupdigetdeviceinterfacedetail-getlasterror-shows-1784-error-inv
//
// Don't ask. Just do what they tell you.
// -----------------------------------------------------------------
#ifdef BUILD_64
pDidd->cbSize = 8;
#else
pDidd->cbSize = 6;
#endif
// -----------------------------------------------------------------
if (!SetupDiGetDeviceInterfaceDetail(
hDevInfo,
&devIntData,
pDidd,
dwRequiredSize,
&dwRequiredSize,
nullptr))
{
std::cerr << "Cannot get interface detail: " << ::GetLastError());
}
else
{
// FINALLY: We now have a DevicePath that we can use to open up
// in a Win32 CreateFile() call. That will let us get the
// STORAGE_DEVICE_NUMBER and compare it to the one we were given.
const auto hFile = ::CreateFileW(pDidd->DevicePath, 0, FILE_SHARE_READ, nullptr, OPEN_EXISTING, 0, NULL);
if (INVALID_HANDLE_VALUE != hFile)
{
std::cerr << "Unable to open logical volume: " + devicePath << std::endl;
continue;
}
STORAGE_DEVICE_NUMBER sdnTest;
ZeroMemory(&sdnTest, sizeof(STORAGE_DEVICE_NUMBER));
if (0 == DeviceIoControl(
hDevInfo
IOCTL_STORAGE_GET_DEVICE_NUMBER,
nullptr, // output only so not needed
0, // output only so not needed
&sdnTest,
sizeof(STORAGE_DEVICE_NUMBER),
nullptr,
nullptr))
{
std::cerr << "Unable to determine storage device number: " << ::GetLastError() << std::endl;);
}
else
{
// All this for a one-line test...
foundValidMatch = sdnTest.DeviceNumber == sdn.DeviceNumber;
}
}
}
}
SetupDiDestroyDeviceInfoList(hDevInfo);
return foundValidMatch;
}
I hope this saves someone a headache