Hi,
i wonder why the VendorIdOffset, ProductIdOffset, ProductRevisionOffset, SerialNumberOffset hold ASCII data and do not point to UNICODE strings. Does this have any reason? Is the data read from the firmware ASCII itself?
K.
Yes… the data is supplied just as it comes back from the device. For example, the data comes from IDENTIFY or the VPD Page 83 stuff.
Hope that helps,
Peter
OSR
Ok thanks. I am gettin strange results for the serial number, calculated from the offset of SerialNumberOffset. The data looks like this “57554548444a4751505559505451707070707070”, where it should look like “S4HdJFQB311374” (from wmi). Other data calculated from the offset is just fine. Is there anything i must take care of while “handling” the returned string or is possibly something wrong i get, maybe a wrong address pointing somwhere? The data returned never changes, it always looks the same but it must be wrong acording to wmi and other tools.
First, are you determining the correct return data length?
There is nothing special you need to do if you’re using the IOCTL_STORAGE_QUERY_PROPERTY, you get back a PUCHAR @ pDescriptor + pDescriptor->SerialNumberOffset
This works fine for me.
Hmmmm… Mr. Guemruekcue … I’ve got to say neither of those looks like a hard drive serial number, at least to ME.
I’ve never seen a lower case character in a serial number, for example.
Kenny’s right: There’s exactly zero mystery to using IOCTL_STORAGE_QUERY_PROPERTY, but if you’re dubious, check the examples in the WDK.
Peter
OSR
Hi,
yes, thats true, neither do they look like useful stuff to me, but this is really what i get. I made a raw dump to a file and uploaded it here so you can view it with a hex editor. This is what i get for my another drive:
http://www.pro-it-education.de/staff/keremg/misc/STORAGE_DEVICE_DESCRIPTOR.bin
I am not sure if i am doing something wrong here, but i dont think so. I am aware of the fact that this is very simple to call and evaluate, but it doest look right to me at some point, at least the serial number seems to be something that must be handled in some way to get a useful result. The targeting application is written in .NET(C#), beside that the code is perfectly ok, since i use it for many other more complicated IOCTLs and memory access successfully, but i get exactly the same results in plain C by using this very simple code:
This is the screenshot of the memory view on the C code:
http://www.pro-it-education.de/staff/keremg/misc/STORAGE_DEVICE_DESCRIPTOR.JPG
int _tmain(int argc, _TCHAR* argv)
{
HANDLE hDrive = NULL;
hDrive = CreateFile(
_T(“\\.\C:”),
GENERIC_READ|GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
0,
NULL);
DWORD BufferReturned = 0;
DWORD InputBufferSize = sizeof(STORAGE_PROPERTY_QUERY);
BYTE buffer[2048] = {0};
memset(&buffer,0,sizeof(buffer));
STORAGE_PROPERTY_QUERY spq;
memset(&spq,0,sizeof(spq));
spq.PropertyId = StorageDeviceProperty;
spq.QueryType = PropertyStandardQuery;
BOOL DIOCtrlResult = DeviceIoControl(
hDrive,
0x2D1400, //IOCTL_STORAGE_QUERY_PROPERTY
&spq,
InputBufferSize,
&buffer,
2048,
&BufferReturned,
NULL);
DWORD gle = GetLastError();
return 0;
}
You have a handle to a volume, not sure if that is supposed to work. Use \.\PhysicalDrive0 instead.
Sent via CM10 on SGH-i747 …
xxxxx@arcor.de wrote:
Hi,
yes, thats true, neither do they look like useful stuff to me, but this is really what i get. I made a raw dump to a file and uploaded it here so you can view it with a hex editor. This is what i get for my another drive:
http://www.pro-it-education.de/staff/keremg/misc/STORAGE_DEVICE_DESCRIPTOR.bin
I am not sure if i am doing something wrong here, but i dont think so. I am aware of the fact that this is very simple to call and evaluate, but it doest look right to me at some point, at least the serial number seems to be something that must be handled in some way to get a useful result. The targeting application is written in .NET(C#), beside that the code is perfectly ok, since i use it for many other more complicated IOCTLs and memory access successfully, but i get exactly the same results in plain C by using this very simple code:
This is the screenshot of the memory view on the C code:
http://www.pro-it-education.de/staff/keremg/misc/STORAGE_DEVICE_DESCRIPTOR.JPG
int _tmain(int argc, _TCHAR* argv)
{
HANDLE hDrive = NULL;
hDrive = CreateFile(
_T(“\\.\C:”),
GENERIC_READ|GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
0,
NULL);
DWORD BufferReturned = 0;
DWORD InputBufferSize = sizeof(STORAGE_PROPERTY_QUERY);
BYTE buffer[2048] = {0};
memset(&buffer,0,sizeof(buffer));
STORAGE_PROPERTY_QUERY spq;
memset(&spq,0,sizeof(spq));
spq.PropertyId = StorageDeviceProperty;
spq.QueryType = PropertyStandardQuery;
BOOL DIOCtrlResult = DeviceIoControl(
hDrive,
0x2D1400, //IOCTL_STORAGE_QUERY_PROPERTY
&spq,
InputBufferSize,
&buffer,
2048,
&BufferReturned,
NULL);
DWORD gle = GetLastError();
return 0;
}
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Hi Kenny,
its the same, i already checked it with both variants,…its always the same. As you can see, the buffer and output is valid as long as you pass enough buffer to store all extra data appended to the structure. I am kinda stuck on this,… 
This seems to be some flipped data of some kind, because if you look at “32534348444a4251303339303431” it seems to be a hex string (and it is). if you convert it to a ascii string, you will get this “2SCHDJBQ039041” and if you take a clooser look at that and compare it with the original hardware serial number wich is this “S2HCJDQB3000914”,…its obvious what has to be done,…
xxxxx@arcor.de wrote:
Ok thanks. I am gettin strange results for the serial number, calculated from the offset of SerialNumberOffset. The data looks like this “57554548444a4751505559505451707070707070”, where it should look like “S4HdJFQB311374” (from wmi).
Now, you do recognize that the first string is almost certainly the hex
representation of ASCII data, don’t you?
C:\Tmp>python
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32
Type “help”, “copyright”, “credits” or “license” for more information.
>> s = “57554548444a4751505559505451707070707070”
>> print s.decode(‘hex’)
WUEHDJGQPUYPTQpppppp
>>
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Besides media vs device serial numbers, sometimes they are different because you get one serial number querying the USB descriptor and a totally different one through SCSI Inquiry.