Skip to content

Control characters in serial number when retrieving specific USB memory information on Windows/Linux #117

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
tatac1 opened this issue Mar 27, 2025 · 4 comments

Comments

@tatac1
Copy link

tatac1 commented Mar 27, 2025

Description
When retrieving information for specific USB memory devices using paccor v1.1.4r11 (Windows), control characters are included in the serial number.

Affected USB Memory Devices

  • Kingston: DataTraveler Exodia DTX/32GB
  • BUFFALO: RUF2-E2G

Steps to Reproduce

  1. Connect the above USB memory device to the Windows device.
  2. Execute allcomponents.ps1.

Expected behavior
The serial number should be displayed correctly without any control characters.

Actual behavior
Control characters are included in the serial number.

Example

JSON

"MANUFACTURER": "BUFFALO","MODEL": "USB Flash Disk","FIELDREPLACEABLE": "true","SERIAL": "ユセル""MANUFACTURER": "Kingston","MODEL": "DataTraveler 3.0","FIELDREPLACEABLE": "true","SERIAL": "0000000005��"

Additional context

  1. The control characters are already present when retrieving information using the following command: Get-PhysicalDisk | select serialnumber,mediatype,manufacturer,model,bustype | where BusType -ne NVMe
  2. Behavior on Linux with the same USB memory devices:
  3. Kingston: No control characters at the end of the serial number.
  4. BUFFALO: The serial number field is not output at all.
  5. Attached the allcomponents.ps1 execution result when the issue occurred.

paccor_result_linux_kingston.txt
paccor_result_linux_buffalo.txt
paccor_result_windows.txt

@tatac1
Copy link
Author

tatac1 commented Mar 28, 2025

I suspected that CP932 might be affecting the issue due to the Japanese locale of my PowerShell execution environment. However, I changed the encoding to UTF-8 and re-tested, but the result remained the same

@iadgovuser29
Copy link
Collaborator

Thank you for posting about this.

Note that the focus of this research is on internal components. And in the near future, paccor will be updated to collect disk information according to the TCG Storage Component Class Registry. It leaves out USB devices at the moment. I'll still have a method to query the scripts.

Are you able to tell what actual values are being reported by your USB devices?

I can see a problem in an assumption that I make in my Linux script that filters text data retrieved from lshw. It only returns a selection of ASCII characters ([0-9A-Za-z:-]+).

Does lshw output the correct data for those devices?
Can you run lsusb -v on each device? lsusb should display the serial from the device as a hex string.

I'm thinking the Windows allcomponents script is accurately saving the data returned by the powershell get-physicaldisk command. Especially after reading point 1 in your post under additional context.

I've had to implement plenty of special processing choices in these scripts. So have others working in this space. That's part of the reason for the newer component class registries.

Some changes I could make for you in these scripts:
I could Trim the control characters from the disk serial found on the Windows side. This could clean up the string for the Kingston device.

And I can make sure I'm not filtering valid UTF8 characters on the Linux side. That should allow the UTF8 characters in the serial on the Buffalo device to be collected on Linux.

What do you think?

@tatac1
Copy link
Author

tatac1 commented Apr 17, 2025

Thank you for your prompt and detailed response, including your proposed solutions.

Regarding the TCG Storage Component Class Registry, I have verified your point that USB mass storage devices are not currently included. Considering their occasional use in server environments, their inclusion could indeed be valuable. As our organization is a TCG member, I will bring this up for discussion with the TCG Infrastructure Work Group.

As requested, I have attached the output from the lshw and lsusb -v commands for both the Kingston and BUFFALO USB drives while connected.

  • Kingston: Your proposal to trim control characters from the serial number retrieved on Windows appears to be a practical approach for this device.
  • BUFFALO: Concerning the BUFFALO drive on Linux, I observed that the lshw output doesn't appear to contain a serial field for this device. Consequently, modifying the character filtering alone might be insufficient to capture the serial number in this instance; it could prove more challenging.

Thank you again for investigating this issue. Please let me know if any further information or testing is required from my end.

lshw.txt

lsusb.txt

@iadgovuser29
Copy link
Collaborator

Is there any indication where Windows got the serialnumber values it reported for your disks?

Both powershell and lshw reported the iManufacturer and iProduct values as manufacturer and model for both USB chassis. iSerialNumber is present for both, but not reported as the disk serial number.

Does using the -json option in lshw change the output of the serial number?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants