15 replies to this topic

[Zharif]

I need an advice from all of the experts here:

 

Does a HD SerialNr always consist of a combination of numbers (integers) and letters (upper and/or lowercase) only?

If Yes, should it be enough to define an ASCII-CharRange between 32 and 127 for it (0 to 31 = non-printable chars)?

 

Or does somebody of you have ever seen a SerialNr on top of an HD-enclosure that

may consist of chars from extended ASCII = ANSI (range between 32 and 255)?

 

Furthermore, is it possible that a HD SerialNr may consist of unicode chars also?

 

To clarify, I'm not talking about SerialNrs seen/determined by external or internal software from your running system.

I mean the SerialNr printed on top of any HD enclosure.

 

 

Thanks much in advance for any reply

[Wonko the Sane]

I need an advice from all of the experts here:

 

Does a HD SerialNr always consist of a combination of numbers (integers) and letters (upper and/or lowercase) only?

If Yes, should it be enough to define an ASCII-CharRange between 32 and 127 for it (0 to 31 = non-printable chars)?

 

Or does somebody of you have ever seen a SerialNr on top of an HD-enclosure that

may consist of chars from extended ASCII = ANSI (range between 32 and 255)?

 

Furthermore, is it possible that a HD SerialNr may consist of unicode chars also?

 

To clarify, I'm not talking about SerialNrs seen/determined by external or internal software from your running system.

I mean the SerialNr printed on top of any HD enclosure.

 

 

Thanks much in advance for any reply

Well, you will need first to tell us how (are you going to put a small camera connected to an OCR system? ) are you going to read the "SerialNr printed on top of any HD enclosure"

 

I know it seems a strange note, bit there are known issues with the way a number of Windows (after XP) subsystems return the value, see:

https://social.techn...mber?forum=ITCG

 

So, personally I would use something like 

hdparm -I \\.\Physicaldriven | FIND "Number"

 

However, no problem, chars 32-127 are fine.

 

Wonko

[erwan.l]

The below command should work too.

WMIC path win32_physicalmedia get serialnumber

I have never encountered "exotic" chars although I am not sure there is a standard there.

A vendor could, technically speaking, come with chars outside of the 32-127 boundary.

 

I have seen softwares reporting the number reverted.

 

I am not sure there is a link between the printed number on the disk and the serial number reported by the disk firmware.

Is the firmware serial number even reported on the disk itself? Never checked it...

It may also be possible to modify the firmware serial number but this is another discussion.

 

Edit : the microsoft link posted by Wonko is quite interesting.

It appears that the result is not reliable when using a scripting engine depending on the user environement : x32 console, x64 console, admin yes/no, etc ...

Definitely better to stick to "good old" binary calling "good old" windows API/hardware IOCTL's

[Zharif]

At first, thanks for replies.
I was in hope of some answers here.
Objective is my foregoing experience in the last year that might causes more confusion.
Due to my "lack of knowledge" let me try to provide some examples:

1. SD-Slots:
Mine is a front panel 4xSD-Combo with 4 additional USB 2.0 and two USB3.0 ports.
On early boot, my Bios screen identifies my SD-Card Controller and returns the ModelName and DevSerialNr.
Name: Generic Storage Device
Serial: 000000000551 (four times for each SD-Card port)

IOCTL_Storage_Query_Property (Storage_Device_Descriptor) returns  the results mentioned above
(Generic Storage Device and 000000000551 for each port).

Inspite, crosschecking via setupapi.dll (
SetupDiGetClassDevsA,
SetupDiGetDeviceInstanceIDA,
SetupDiGetDeviceInterfaceDetailA,
SetupDiGetDeviceRegistryPropertyA
) I get DevSerialNr "000000001832" for each port.
The underlying code determines values that can be checked via Diskmanagement console by right-clicking
"Device", context-menu "Properties", tab "Details", ComboBox "Properties" and entry "Device Instance Path".

NirSofts "USBDevview" for example, also seems to return values from setupapi.dll (kind of "technique" mentioned before).
Results are Generic Storage Device and 000000001832 (just for reference).

So, let me ask - which DevSerialNr should be trusted here?


2. Now some tests with a 2.5" SATA HDD
Printed DevModel and DevSerialNr are Hitachi HTS545050A7E380 and 39G35G6S (see pic at bottom of this post).
For my tests I use an usb adapter cable from Raidsonic (Icy Box IB-AC603a-U3).

While connected directly via sata interface and 7 pin power connector to the sata port of my mainboard
(Asus-P8Z68-V-LE) the returned ModelName and DevSerialNr of IOCTL_Storage_Query_Property is identical
to the printed DevModel and DevSerialNr (Hitachi HTS545050A7E380 and 39G35G6S).
This behaviour can be replicated for nearly any of the HDDs I own (12 of 15 tested).

The same HDD - connected via usb adapter cable mentioned before provides different results.
IOCTL_Query_Property AND setupapi.dll return "ASMT 2115 USB Device" and "00000000000000000000".
I crosschecked with values from NirSofts USBDevview. These are are identical.
As we already know, it seems that the usb adapter controller is read instead.
This behaviour can also be replicated for my HDDs.

So, indeed it "seems" to be questionable if there's a link between the printed DevSerialNr
and the one that is read if a HDD is connected via usb adapter cables.

On the other side, smartmontools (smartctl) is very little impressed.
It always return the correct DevModelName and DevSerialNr although the HDD is connected via USB.
It might be very interesting to know what "techniques" are used here.
I know that a kind of database (that must be updated from time to time) is used to identify the devices.


3. DevSerialNrs in ASCI-range between 31-127:
I own an old CnMemory Core USB flash drive (size: 1GB).
The byte array data sequence (5 bytes) for the DevSerialNr via IOCTL_Query_Property is
0 96:  = 0x60 = Chr'`'
1 69:  = 0x45 = Chr'E'
2 25:  = 0x19 = non-printable
3 18:  = 0x12 = non-printable
4 255: = 0xFF = Chr'ÿ'
As you see some are out of the expected ASCI-range.
It is interesting to see that the retrieved "DevSerialNr" changes everytime I unconnect it and then
reconnect it to a different USB port of my pc (any of those at the front- or at the backpanel).

While using setupapi code I always get DevSerialNr "AA04012700017809".
USBDevview and diskmanagement properties return identical results.
Smartmontools quits with message: "Unknown USB bridge [0x090c:0x1000]".


Let's be honest without beeing too philosophical.
If you want to recieve the DevSerialNr of a HDD, a printed reference exist.
For well known reasons there's not unlimited access the printed DevSerialNr.
Therefore, if coding-based retrievements seem to distinguish between connection settings and
return different results, everyone who develops e.g. API/WMIC-solutions should state that these are
definitely not able to return the correct DevSerialNr if the Device is connected via USB.
Although I fear that "The Finder" will provide the opposite (please do if possible),
I've never seen a reference to clarify this issue from anyone in the web.
Thereby, it's very important to clarify this limitations for potential users.
Reason is that they don't get what they are intended to get.
Or, a little bit more precise: they sometimes don't get what they are intended to get.

I found an interesting article that try to explain "some?" of these issues.

It also confirms, that the DevSerialNr can be changed temporarely.
https://digfor.blogs...ers-unique.html

Attached Files

•  IMG_1534.JPG   22.52KB   1 downloads

[erwan.l]

Issue is with USB <-> (S)ATA Bridges.

There are lots of interesting details in Rufus source code (here) which is also linking to scsiata.cpp from Smartmontools.

 

• IOCTL_Storage_Query_Property is one way to retrieve basic datas (such as the S/N) from a storage device (this is what CloneDisk does) - will use the storage filter driver.
• IOCTL_SCSI_PASS_THROUGH is another way to deal (send/receive) with a the storage device which works in most scenarios nowawadays - will use the storport driver.
• ioctl_ata_pass_through also works - will use the atapi driver.
• And you still have the older IOCTL_IDE_PASS_THROUGH (undocumented probably not recommended nowadays).
• And in some limited scenarios (ATA IDENTIFY), you can also use IOCTL_SCSI_MINIPORT + SMART_RCV_DRIVE_DATA.

And I am probably missing some other possibilities although the above should pretty much cover it 

 

Everytime it will depend on your software (which windows version but also which driver) and your hardware (chipset, firmware, etc).

 

These days (on windows at least), I believe one need to combine these multiple combinations like :

-first attempt IOCTL_Storage_Query_Property

-then try SMART_RCV_DRIVE_DATA

-and finally end with IOCTL_SCSI_PASS_THROUGH

 

I did not dive yet into smartmon tools for windows, but I am pretty sure you will see a mix of IOCTL's.

 

Regards,
Erwan

[Wonko the Sane]

Not only, you (Zharif) just tried to shift the topic from what you asked originally which was HDD or hard disk drives to *any storage media* that may (or may not) be similar to a HDD device.

 

In a nutshell, you SD card reader is to all effects a USB bridge, very likely of the peculiar type for which Windows assigns a (actually 4) drive letter(s) even with no media inserted, in any case that - at least in theory - is designed for "removable media" (which is very unlike a Hard Disk Device).

 

In the case of a USB stick (which is NOT a Hard Disk Device) the Serial number is the serial number of the controller, it can be changed with the specific manufacturer utility at will, and is well outside the "normal" settings, and besides that, your specific stick is behaving "strangely", one would need to find the controller in it and have alook at it with Manufacturer's Tool (if available).

 

And more or less the same goes for USB to IDE or USB to SATA bridges, some will report "pass - through" the actual serial number of the HDD inside, some will only expose the serial number of the controller.

 

It's a mess.

 

Still a hard disk device will have a serial that is ASCII, rest assured.

 

Wonko

[erwan.l]

In the case of a usb key, I get consistent results between usbdeview (using setupapi) and clonedisk (using iotcl_storage_query_property).

Smartctl gives me a "/dev/sdb: Unknown USB bridge [0x0951:0x1653]".

 

[erwan.l]

And now using one of these ugly SD card readers (displaying 4 empty drive letters by default), I get an "almost" consistent result (on" digit difference).

Smartctl gives me an error "Unknown USB bridge".

 

[erwan.l]

Finally testing a usb disk (probably using a usb to sata bridge) I get a consistent result all the way (including smartctl).

 

[Wonko the Sane]

Unknown USB bridge [0x0951:0x1653]".

0x0951 means "Kingston"

0x1653 should mean DT 100 G2

 

But more loosely Smartctrl is (correctly IMHO) returning a "suffusion of yellow", simply it is NOT intended to be used on USB sticks (that are NOT Hard Disk Devices).

 

So, once said (again if it was needed) that it makes little sense to send ATA (or S.M.A.R.T.) commands to devices that are not ATA and have no idea what S.M.A.R.T. is , the point remains, a number of ATA (both IDE/PATA and SATA) USB bridges are not allowing some pass-through commands, see:

https://www.smartmontools.org/wiki/USB

https://www.smartmon...ted_USB-Devices

 

As a side note, it would be interesting to test Smartmon on one of those USB sticks that are NOT USB sticks but rather a mini-SSD (SATA) with a USB to SATA bridge (and that conversely are Hard Disk Devices).

 

Wonko

[erwan.l]

 

So, once said (again if it was needed) that it makes little sense to send ATA (or S.M.A.R.T.) commands to devices that are not ATA and have no idea what S.M.A.R.T. is , the point remains, a number of ATA (both IDE/PATA and SATA) USB bridges are not allowing some pass-through commands, see:

https://www.smartmontools.org/wiki/USB

https://www.smartmon...ted_USB-Devices

 

 

 

Absolutely !

Thus, to stick to the topic, it is possible to retrieve a S/N thru other means (i.e not ATA or SMART commands) but then the result is less reliable.

[Zharif]

Not only, you (Zharif) just tried to shift the topic from what you asked originally which was HDD or hard disk drives to *any storage media* that may (or may not) be similar to a HDD device.

 

Wonko, do you really think I didn't know that? But anyway, thanks for the reminder.

 

Back to my original question:

Both of your last replies Wonko were really, really helpful.

At least they cover many of my "secret" questions behind.

The ASCI sequence issue for "real" HDDevs also seems to be answered - thanks.

Okay, topic closed?

 

erwan.l,

at least, your pics, particulary the one about the USB disk didn't gave my any hint if the determined DevSerialNr is identical to the printed one.

For me, as this was one (hidden) intention to open this topic, this seems most important. It seems, as if you really don't care about this.

Furthermore I'm not able to understand why you're posting examples that seem to return valid results. Wouldn't it be more target-aimed (in my opinion) to provide examples (and may be possible explanations/solutions) where results seem to differ (as previously posted by me). At least you proved that you cannot replicate the issues I ran into (no offend at all).

 

BTW, a big thanks for yours active participation to this topic.

[cdob]

I've seen numbers and upper chars at a real HDD: [0..9,A..Z]
It's about warrany too, a manufactuerer likes to make simple markers.
It makes no sense to use 8 bit or unicode chars, this will lead to cunfusion.

USBview list the serial numbers
https://docs.microso...ebugger/usbview
https://github.com/M...ter/usb/usbview

http://www.emmet-gra...ialNumbers.html

[erwan.l]

 

erwan.l,

at least, your pics, particulary the one about the USB disk didn't gave my any hint if the determined DevSerialNr is identical to the printed one.

For me, as this was one (hidden) intention to open this topic, this seems most important. It seems, as if you really don't care about this.

Furthermore I'm not able to understand why you're posting examples that seem to return valid results. Wouldn't it be more target-aimed (in my opinion) to provide examples (and may be possible explanations/solutions) where results seem to differ (as previously posted by me). At least you proved that you cannot replicate the issues I ran into (no offend at all).

 

 

Hi Zharif,

 

Sorry if you feel I did not contribute to this topic.

I may have missed your "secret" question(s).

 

My intention was, wearing my developper hat, to :

-provide some explanations on the different ways to retrieve this serial number

-discuss about why we sometimes get inconsistent results using different software and hardware

-eventualy provide some guidance (still from a dev point of view) to maximise chances to get a proper S/N

-illutrate different scenarios (a usb key, a card reader, a usb disk ...)

 

Hopefully, the details provided there will be of some help for others if not for you.

 

Regards,

Erwan

[Wonko the Sane]

Okay, topic closed?

On the contrary, the initial question is answered, but the can of worms has been (and remains) open.

And I will add a random piece of info, though each and every USB stick around wlll generally have a serial number, it is usually possible to remove it with the suitable Manufacturer Tool and the results may in some cases surprise as some tools may "lose" the stick.
I remember having issue when testing a "strange" program, Pravaya V3 until I managed to undestand that the issue was my stick that ended up with no serial number after other experiments.

And, on the other hand, when you have a stick with two LUN's it is to be seen if the Serial Number (that is one only) is modified for the two devices or it remains the same.


Wonko

[Zharif]

erwan.l
I wrote:

BTW, a big thanks for yours active participation to this topic.

You wrote:

Sorry if you feel I did not contribute to this topic.

     

   ???

 

Please, do not misunderstand my wording. For me, your contribution is most appreciated.
I just wanted to underline that SOME of your "developer hat" intentions were already
covered by me in my second post. As you already know, my approaches to retrieve DeviceInfo (zDinfo)
uses exactly the same technics in VB as you did in Delphi(clonedisk). My info utility uses the
QueryProperty approach and a fully working code for the setupapi (from Emmet Gray, by the way).
But Despite, we get different results.

Will go more into detail soon.
Zharif