USB Memorystick - Serial auslesen
Ulrich Korndoerfer
weiß jemand, wie man aus einem handelsüblichen USB-Massenspeicher
(USB-Memorystick) die Seriennummer auslesen kann?
Gemeint ist damit die eindeutige, nicht nachträglich änderbare
Seriennummer, die der Hersteller des Sticks dem USB-Controller (neben
VID,PID etc) verpaßt.
Für USB-HIDs könnte ich das noch hinkriegen (da hilft die hid.dll).
Nützt mir aber nichts, ich brauche einen USB-Stick.
--
Ulrich Korndoerfer
VB tips, helpers, solutions -> http://www.proSource.de/Downloads/
-----------------------------------------------------------------------
Plea for a bright future for VB classic.
Sign the petition to Microsoft: -> http://classicvb.org/petition/
-----------------------------------------------------------------------
Michael Alexander
Vielleicht hilft dir das. Ich habs nur überflogen, es könnte die benötigte
Info anzeigen.
http://www.Planet-Source-Code.com/vb/scripts/ShowCode.asp?txtCodeId=31520&lngWId=1
Gruß
Michael
"Ulrich Korndoerfer" <ulrich_wa...@prosource.de> schrieb im
Newsbeitrag news:43E164F2...@prosource.de...
Michael Alexander
Wahrscheinlich gehts einfacher damit:
Option Compare Database
'--------------------------------------------------------------
' Copyright ©1996-2002 VBnet, Randy Birch, All Rights Reserved.
' Terms of use http://www.mvps.org/vbnet/terms/pages/terms.htm
'--------------------------------------------------------------
Option Explicit
Private Declare Function GetVolumeInformation Lib "kernel32" _
Alias "GetVolumeInformationA" _
(ByVal lpRootPathName As String, _
ByVal lpVolumeNameBuffer As String, _
ByVal nVolumeNameSize As Long, _
lpVolumeSerialNumber As Long, _
lpMaximumComponentLength As Long, _
lpFileSystemFlags As Long, _
ByVal lpFileSystemNameBuffer As String, _
ByVal nFileSystemNameSize As Long) As Long
Private Sub Command1_Click()
Dim PathName As String
Dim DrvVolumeName As String
Dim DrvSerialNo As String
'the drive to check
PathName$ = "l:\"
rgbGetVolume PathName, DrvVolumeName, DrvSerialNo
'show the results
MsgBox " Drive Statistics for: " & UCase$(PathName) & vbCrLf & " Volume
Label: " & DrvVolumeName & vbCrLf & " Volume Serial No: " & DrvSerialNo
End Sub
Private Sub rgbGetVolume(PathName As String, _
DrvVolumeName As String, _
DrvSerialNo As String)
'create working variables
'to keep it simple, use dummy variables for info
'we're not interested in right now
Dim r As Long
Dim pos As Integer
Dim hword As Long
Dim HiHexStr As String
Dim lword As Long
Dim LoHexStr As String
Dim VolumeSN As Long
Dim MaxFNLen As Long
Dim UnusedStr As String
Dim UnusedVal1 As Long
Dim UnusedVal2 As Long
'pad the strings
DrvVolumeName = Space$(14)
UnusedStr = Space$(32)
'do what it says
r = GetVolumeInformation(PathName, _
DrvVolumeName, _
Len(DrvVolumeName), _
VolumeSN&, _
UnusedVal1, UnusedVal2, _
UnusedStr, Len(UnusedStr))
'error check
If r = 0 Then Exit Sub
'determine the volume label
pos = InStr(DrvVolumeName, Chr$(0))
If pos Then DrvVolumeName = Left$(DrvVolumeName, pos - 1)
If Len(Trim$(DrvVolumeName)) = 0 Then DrvVolumeName = "(no label)"
'determine the drive volume id
'hword = HiWord(VolumeSN)
'lword = LoWord(VolumeSN)
'HiHexStr = Format$(Hex(hword), "0000")
'LoHexStr = Format$(Hex(lword), "0000")
'DrvSerialNo = HiHexStr & "-" & LoHexStr
DrvSerialNo = VolumeSN
End Sub
Private Function HiWord(dw As Long) As Integer
HiWord = (dw And &HFFFF0000) \ &H10000
End Function
Private Function LoWord(dw As Long) As Integer
If dw And &H8000& Then
LoWord = dw Or &HFFFF0000
Else
LoWord = dw And &HFFFF&
End If
End Function
'--end block--'
Gruß
Michael
"Ulrich Korndoerfer" <ulrich_wa...@prosource.de> schrieb im
Newsbeitrag news:43E164F2...@prosource.de...
Ulrich Korndoerfer
Michael Alexander schrieb:
> Hallo!
> Wahrscheinlich gehts einfacher damit:
Sorry, das tuts nicht (Antwort auf beide Posts). Es geht nicht darum,
- die Registry auszulesen (die die gewünschte Information sowieso nicht
enthält)
- Volume Information auszulesen
Es geht darum, aus einem USB-Controller die Devicedescriptions
auszulesen. Und zwar dann, wenn dieser Controller gerade "online" ist.
In den Devicedescriptions enthalten ist die Serial ID.
Klaus Heinrich
mal aus Neugier: was liefert das Coding denn zurück ?
Zumindest liest es bei mir was aus
Gruß Klaus
Ulrich Korndoerfer schrieb:
Thorsten Doerfler
> mal aus Neugier: was liefert das Coding denn zurück ?
> Zumindest liest es bei mir was aus
Es liest die Datenträger-Seriennummer aus, die bei jedem Formatieren
des Datenträgers neu erstellt wird. Ulrich möchte aber die
unveränderliche Geräte-ID auslesen.
Thorsten Dörfler
--
vb-hellfire - einfach anders
http://www.vb-hellfire.de/
Ulrich Korndoerfer
Ulrich Korndoerfer schrieb:
> ...
> - die Registry auszulesen (die die gewünschte Information sowieso nicht
> enthält)
Der erwähnte Code von Planet Source Code liest seine Informationen aus
der Registry. Unter den Informationen, die *dieser* Code ausliest, ist
die Serial ID nicht dabei. Was aber nicht heißt, daß sie nicht in der
Registry zu finden wäre, da Windows beim Enumerieren von USB Geräten
diese verwendet. Trotzdem, selbst wenn dieser Code diese Info aus der
Registry lesen würde, wäre mir damit nicht gedient. Denn dann wüßte ich
nur, daß ein Gerät mit dieser ID mal an diesem PC angeschlossen war. Ich
will aber wissen, ob in dem Moment, an dem ich die ID lese, das Gerät
angeschlossen ist. Und am sichersten geht das, indem ich die ID direkt
aus dem Gerät auslese. Sicherheit bzw. Gewissheit ist hier wichtig, weil
ich damit die Lizenzierung einer Software durchführen will.
Uwe Sieber
Ulrich Korndoerfer wrote:
> Hallo NG,
>
> weiß jemand, wie man aus einem handelsüblichen USB-Massenspeicher
> (USB-Memorystick) die Seriennummer auslesen kann?
>
> Gemeint ist damit die eindeutige, nicht nachträglich änderbare
> Seriennummer, die der Hersteller des Sticks dem USB-Controller (neben
> VID,PID etc) verpaßt.
Vendor- und Product ID und die Hardware-Seriennummer bekommt
man per DeviceIoControl und IOTL_STORAGE_QUERY_PROPERTY.
Bei Festplatten bekommt man tatsächlich die Seriennummer -
bei den Sticks und USB-Platten die mir bisher untergekommen
sind, kommen zwar Vendor- und Product ID, bei SerialNumberOffset
kommt aber immer Null, also keine Seriennummer.
Gruß Uwe
Ulrich Korndoerfer
Uwe Sieber schrieb:
> ...
> Vendor- und Product ID und die Hardware-Seriennummer bekommt
> man per DeviceIoControl und IOTL_STORAGE_QUERY_PROPERTY.
> Bei Festplatten bekommt man tatsächlich die Seriennummer -
> bei den Sticks und USB-Platten die mir bisher untergekommen
> sind, kommen zwar Vendor- und Product ID, bei SerialNumberOffset
> kommt aber immer Null, also keine Seriennummer.
Die Sticks oder USB-Platten sollten aber (zumindest in der Regel) eine
haben. Vielleicht ist IOCTL_STORAGE_QUERY_PROPERTY ja nicht geeignet, um
die Serial ID aus einem *USB*-Device auszulesen. Der Zugang über
IOCTL_STORAGE_QUERY_PROPERTY war ja wahrscheinlich schon möglich bevor
es USB gab (wenigstens unter Windows). Die SerialID, die ich haben
möchte, ist in einem Devicedescriptorblock vergraben, dessen Struktur
die USB Org festgelegt hat und ebenso hat diese USB Org das Protokoll
festgelegt, welches zum Abfragen hergenommen werden muß.
Früher konnten die Devicetreiber direkt auf die IDE/SCSI-Schnittstelle
zugreifen und bedienten sich des entsprechenden Protokolls. Bei USB
Platten oder Sticks liegt nun die USB Schnittstelle dazwischen. Ich
könnte mir vorstellen, daß für IOCTL_STORAGE_QUERY_PROPERTY die
USB-Schnittstelle transparent ist (Windows handelt das intern) und
Befehle direkt an die drunter liegende IDE/SCSI-Schnittstelle
weitergeleitet werden. Einen IDE/SCSI-Befehl zum Auslesen einer
SerialID, die in einem USB-Devicedescriptor liegt, gibts aber nicht.
Zumindest einen Versuch wert wäre, wie mir scheint,
IOCTL_INTERNAL_USB_SUBMIT_URB und dazu ein passender URB. Damit kann man
anscheinend direkt auf das USB-Device zugreifen.
Nur, wenn ich mit der Microsoft Doku zu dem Thema zurecht käme, bräuchte
ich hier nicht zu fragen, dann hät ichs schon programmiert. Nicht das
ich nicht C-Code lesen könnte. Aber ich finde keine passenden Beispiele
und es fehlt mir das "big picture", der "rote Faden". Es sind weniger
die Details, sondern eher die "basics", die mir fehlen (zumindest momentan).
Ich bräuchte jemanden, der mich auf "die Spur" setzt. Zb welche
Funktionen in welcher Reihenfolge aufgerufen werden müssen (dieser
Zusammenhang geht in der MS Doku ja besonders leicht verloren).
Ganz grob ist mir die Sache soweit klar, das ich mit CreateFile ein
Devicehandle holen muß. Dabei muß als Filename der Devicename in
spezieller Notation vorgeben werden und dieser Devicename muß in einem
vorgeschaltetem Stück erst gefunden werden. Und das ist die
Vorgehensweise für WIN2K und größer. Für Win98 siehts wieder etwas
anders aus.
Anschließend wird DeviceIoControl mit dem Devicehandle und weiteren
Parametern aufgerufen. Die richtigen Parameter zu finden ist aber nicht
so einfach.
Thorsten Albers
<43E37324...@prosource.de>...
> Ich bräuchte jemanden, der mich auf "die Spur" setzt. Zb welche
> Funktionen in welcher Reihenfolge aufgerufen werden müssen (dieser
> Zusammenhang geht in der MS Doku ja besonders leicht verloren).
> Ganz grob ist mir die Sache soweit klar, das ich mit CreateFile ein
> Devicehandle holen muß. Dabei muß als Filename der Devicename in
> spezieller Notation vorgeben werden und dieser Devicename muß in einem
> vorgeschaltetem Stück erst gefunden werden. Und das ist die
> Vorgehensweise für WIN2K und größer. Für Win98 siehts wieder etwas
> anders aus.
> Anschließend wird DeviceIoControl mit dem Devicehandle und weiteren
> Parametern aufgerufen. Die richtigen Parameter zu finden ist aber nicht
> so einfach.
Mit USB-Geräten habe ich in dieser Hinsicht noch nicht gearbeitet, aber
Deiner Beschreibung nach scheint mir das Prinzip das gleiche zu sein wie
bei ASPI- oder auch S.M.A.R.T.-Geräten.
Nachdem Du mit CreateFile() den Treiber zur Kommunikation geöffnet hast,
schickst Du über DeviceIoControl() entsprechende Treiber-Kommandos (ein
solches wäre z.B. IOCTL_STORAGE_QUERY_PROPERTY) an den Treiber, und wenn Du
alles richtig abgeschickt und Glück hast, antwortet Dir der Treiber in den
Rückgabe-Parametern von DeviceIoControl().
hDevice
Handle des geöffneten Treibers (CreateFile())
dwIoControlCode
Treiber-Kommando-Code; die im MSDN dokumentierten FSCTL_*- und
IOCTL_*-Treiber-Kommando-Konstanten beziehen sich in der Regel auf die
Kommunikation mit einem Treiber für angeschlossene Laufwerke ("VWIN32.VXD"
auf Windows 9x, "...PhysicalDrive0" etc. auf NT); für ASPI- und
S.M.A.R.T.-Geräte, und vermutlich auch für USB-Geräte, sind sie meist nicht
verwendbar; stattdessen mußt Du Dir die Kommandos heraussuchen, die der
verwendete Treiber unterstützt bzw. unterstützen sollte, also aus dessen
Dokumentation. Eine gute Quelle für USB-Geräte ist hier m.W. das MS Driver
Development Kit (DDK). Ansonsten finden sich umfangreiche Informationen auf
den Web-Seiten von INTEL.
Zu jedem Treiber-Kommando-Code gibt es in der Regel einen speziellen Device
Descriptor Block für die Rückgabe, wenn zusätzliche Daten übergeben werden
müssen auch einen Device Descriptor Block für die Übergabe. "Device
Descriptor Block" ist dabei letztlich ein etwas blumigerer Ausdruck für
"Struktur", denn es handelt sich einfach nur um einen Speicherblock, in
welchem an bestimmten Offsets bestimmte Daten stehen. In der Regel ist so
ein Device Descriptor Block byte-gepackt, d.h. er ist nicht VB-kompatibel.
Deshalb ist das meiner Erfahrung nach beste Verfahren, den Device
Descriptor Block in einem Byte-Array zu übergeben bzw. zurückgeben zu
lassen.
Bei einem S.M.A.R.T.-Gerät können z.B. mit dem Treiber-Kommando
DFP_GET_VERSION Versionsdaten abgefragt werden (Windows 9x):
Private Type typGETVERSIONOUTPARAMS ' 24 Bytes, kein Padding
bVersion As Byte ' Binary driver version.
bRevision As Byte ' Binary driver revision.
bReserved As Byte ' Not used.
bIDEDeviceMap As Byte ' Bit map of IDE devices.
lCapabilities As Long ' Bit mask of driver
capabilities.
alReserved(0 To 3) As Long ' For future use.
End Type
Const DFP_GET_VERSION As Long = &H74080
hSmart = CreateFile("\\.\SMARTVSD", _
(GENERIC_READ Or GENERIC_WRITE), _
(FILE_SHARE_READ Or FILE_SHARE_WRITE), _
ByVal 0&, _
OPEN_EXISTING, _
0, _
ByVal 0&)
If hSmart Then
lResult = DeviceIoControl(hSmart, _
DFP_GET_VERSION, _
ByVal 0&, 0, _
VERSIONPARAMS, Len(VERSIONPARAMS), _
lBytesReturned, _
ByVal 0&)
Call CloseHandle(hSmart)
End If
-----
Und ein S.M.A.R.T.-Beispiel für DFP_RECEIVE_DRIVE_DATA mit einem Eingabe-
und einem Ausgabe-Block:
Private Type typIDEREGS ' 8 Bytes, kein Padding
bFeaturesReg As Byte ' Used for specifying SMART "commands".
bSectorCountReg As Byte ' IDE sector count register
bSectorNumberReg As Byte ' IDE sector number register
bCylLowReg As Byte ' IDE low order cylinder value
bCylHighReg As Byte ' IDE high order cylinder value
bDriveHeadReg As Byte ' IDE drive/head register
bCommandReg As Byte ' Actual IDE command.
bReserved As Byte ' reserved for future use. Must be
zero.
End Type
Private Type typSENDCMDINPARAMS ' 33 Bytes, kein Padding
lBufferSize As Long ' Buffer size in bytes
IRDRIVEREGS As typIDEREGS ' Structure with drive register values.
bDeviceNumber As Byte ' Physical drive number to send
command to (0,1,2,3).
abReserved(0 To 2) As Byte ' Reserved for future expansion.
alReserved(0 To 3) As Long ' For future use.
'abBuffer(0 To 0) As Byte ' Input buffer.
End Type
Private Type typDRIVERSTATUS ' 12 Bytes, kein Padding
bDriverError As Byte ' Error code from driver, or 0 if no
error.
bIDEStatus As Byte ' Contents of IDE Error register.
' Only valid when bDriverError is
SMART_IDE_ERROR.
bReserved(0 To 1) As Byte ' Reserved for future expansion.
alReserved(0 To 1) As Long ' Reserved for future expansion.
End Type
Private Type typSENDCMDOUTPARAMS ' 17 Bytes, kein Padding
lBufferSize As Long ' Size of bBuffer in bytes
DRIVERSTATUS As typDRIVERSTATUS ' Driver status structure.
'abBuffer(0 To 0) As Byte ' Buffer of arbitrary length in which
to store
' the data read from the drive
End Type
Const IDENTIFY_BUFFER_SIZE As Long = 512
Dim SCIP As typSENDCMDINPARAMS
Dim SCOP As typSENDCMDOUTPARAMS
With SCIP
.lBufferSize = IDENTIFY_BUFFER_SIZE
With .IRDRIVEREGS
.bSectorCountReg = 1
.bSectorNumberReg = 1
.bDriveHeadReg = &HA0 Or ((bDeviceNum And 1) * (2 ^ 4))
.bCommandReg = bIDCmd
End With
.bDeviceNumber = bDeviceNum
End With
lBufferLen = Len(SCOP) + IDENTIFY_BUFFER_SIZE
ReDim abBuffer(0 To (0 + lBufferLen& - 1)) As Byte
pBuffer = VarPtr(abBuffer(FIRSTINDEX))
hSmart = CreateFile("\\.\SMARTVSD", _
(GENERIC_READ Or GENERIC_WRITE), _
(FILE_SHARE_READ Or FILE_SHARE_WRITE), _
ByVal 0&, _
OPEN_EXISTING, _
0, _
ByVal 0&)
If hSmart Then
lResult = DeviceIoControl(hSmart, _
DFP_RECEIVE_DRIVE_DATA, _
SCIP, _
Len(SCIP), _
ByVal pBuffer, lBufferLen, _
lBytesReturned, _
ByVal 0)
Call CloseHandle(hSmart)
If lResult Then
If lBytesReturned Then
' Rückgabe-Daten aus pBuffer auslesen
End If
End If
End If
Das nur, um zu zeigen, wie so etwas prinzipiell über DeviceIoControl()
laufen kann. Vielleicht hilft es Dir ja weiter...
--
----------------------------------------------------------------------
THORSTEN ALBERS Universität Freiburg
albers@
uni-freiburg.de
----------------------------------------------------------------------
Dieter Mayer
Thomas Friehoff
Kopierschutzverfahrens nötig ist:
Set wmiServices = GetObject("winmgmts:")
Set wmiDiskDrives = wmiServices.InstancesOf("Win32_DiskDrive")
For Each wmiDiskDrive In wmiDiskDrives
Debug.Print "Disk drive Caption: " & wmiDiskDrive.Caption & "
DeviceID: " & wmiDiskDrive.DeviceID & " " & wmiDiskDrive.PNPDeviceID
strEscapedDeviceID = Replace(wmiDiskDrive.DeviceID, "\", "\\",
1, -1, vbTextCompare)
Set wmiDiskPartitions = wmiServices.ExecQuery("ASSOCIATORS OF
{Win32_DiskDrive.DeviceID=""" & strEscapedDeviceID & """} WHERE AssocClass =
Win32_DiskDriveToDiskPartition")
For Each wmiDiskPartition In wmiDiskPartitions
Set wmiLogicalDisks = wmiServices.ExecQuery("ASSOCIATORS OF " &
"{Win32_DiskPartition.DeviceID=""" & wmiDiskPartition.DeviceID & """} WHERE
AssocClass = Win32_LogicalDiskToPartition")
For Each wmiLogicalDisk In wmiLogicalDisks
Set DriveLetterInfo = New clsWMIDriveLetterInfo
DriveLetterInfo.DriveLetter = wmiLogicalDisk.DeviceID
DriveLetterInfo.DrivePNPID = Clean(wmiDiskDrive.PNPDeviceID)
DriveLetterInfos.Add DriveLetterInfo
Next
Next
Next
For Each DriveLetterInfo In DriveLetterInfos
Debug.Print DriveLetterInfo.DrivePNPID & " = " &
DriveLetterInfo.DriveLetter
Next
Die "DrivePNPID" ist für jeden Stick unterschiedlich. Und der "DriveLetter"
ist der Laufwerksbuchstabe mit dem der Stick beschreibbar ist. Achtung
könnten u.U. mehrere sein, wenn auf dem Stick mehrere Partitionen angelegt
sind.
MfG
TF
Klaus Heinrich
sieht interessant aus, unter vb6 bekomme ich allerdings nur Fehlermeldungen.
Ist der Code für .NET ?
Gruß Klaus
Thomas Friehoff schrieb:
Thomas Friehoff
Ich habe den Code aus einigen Procedure zusammenkopiert.
Fehlermeldung: Beim Übersetzen oder beim Ausführen?
Thomas
P.S.: Dast Du dir die Klasse clsWMIDriveLetterInfo mit den nötigen Feldern
erzeugt ?
"Klaus Heinrich" <te...@test.de> schrieb im Newsbeitrag
news:ds294a$1rsj$1...@ulysses.news.tiscali.de...
Peter Götz
> Dieser Code sollte alles beinhalten was zum Erzeugen eines
> Kopierschutzverfahrens nötig ist:
Er enthält keine Deklarationen für die verwendeten Objekte (wmiDiskDrives
usw.), was zu Fehlern bei Option Explicit führt.
Ein weiterer Fehler wird ausgelöst, weil weder eine Deklaration noch Code
für die Klasse DriveLetterInfo vorhanden ist.
Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tips u. Beispielprogrammen)
Peter Götz
> weiß jemand, wie man aus einem handelsüblichen USB-Massenspeicher
> (USB-Memorystick) die Seriennummer auslesen kann?
>
> Gemeint ist damit die eindeutige, nicht nachträglich änderbare
> Seriennummer, die der Hersteller des Sticks dem USB-Controller (neben
> VID,PID etc) verpaßt.
Ich habe hier einige solcher Speichersticks von div. Herstellern mit WMI
untersucht.
Eine eindeutige Seriennummer habe ich leider bei keinem gefunden. Der Wert
war jeweils NULL.
PNPDeviceID und div. andere mit WMI lesbare IDs unterscheiden sich hier nur
bei Sticks verschiedener Hersteller. Bei unterschiedlichen Sticks des
gleichen Herstellers waren alle IDs, die ich bisher mit WMI untersuchen
konnte, gleich oder eben NULL. Unterschiede konnte ich nur bei Sticks
unterschiedlicher Hersteller feststellen.
Hast Du eine genaue Spezifikation, welche beschreibt, welche der vielen IDs
Du genau suchst?
Ulrich Korndoerfer
Thorsten Albers schrieb:
> ...
> Mit USB-Geräten habe ich in dieser Hinsicht noch nicht gearbeitet, aber
> Deiner Beschreibung nach scheint mir das Prinzip das gleiche zu sein wie
> bei ASPI- oder auch S.M.A.R.T.-Geräten.
> Nachdem Du mit CreateFile() den Treiber zur Kommunikation geöffnet hast,
> schickst Du über DeviceIoControl() entsprechende Treiber-Kommandos (ein
> solches wäre z.B. IOCTL_STORAGE_QUERY_PROPERTY) an den Treiber, und wenn Du
> alles richtig abgeschickt und Glück hast, antwortet Dir der Treiber in den
> Rückgabe-Parametern von DeviceIoControl().
> ...
Danke. Muß ich mal ausprobieren (Deinen Code). Die Meinungen, wie man
Festplattendaten ausliest, gehen auseinander, sobald es darum geht, dies
unabhängig von der OS-Version und der Hardware zu tun. Entweder mit
IOCTL_STORAGE_QUERY_PROPERTY oder mit dem von Dir beschriebenen Weg.
In beiden Fällen ist aber mE nicht zu erwarten, daß ich damit die von
mir gesuchte ID bekomme.
Ulrich Korndoerfer
Dieter Mayer schrieb:
> schau Dich mal hier http://www.intel.com/intelpress/usb/ um
> da gibt es ganz gute Tipps
Danke. Da hatte ich mich schon mal umgesehn und mir auch den
Beispielcode für VB geholt. Aber noch nicht ausprobiert und auch nicht
näher angesehen.
Ulrich Korndoerfer
Thomas Friehoff schrieb:
> Dieser Code sollte alles beinhalten was zum Erzeugen eines
> Kopierschutzverfahrens nötig ist:
> ...
Ich suche eine eindeutige, gerätegebundene ID (wie im Ursprungspost
beschrieben).
> ...
> Die "DrivePNPID" ist für jeden Stick unterschiedlich. Und der "DriveLetter"
> ist der Laufwerksbuchstabe mit dem der Stick beschreibbar ist. Achtung
> könnten u.U. mehrere sein, wenn auf dem Stick mehrere Partitionen angelegt
> sind.
Die PNPDeviceID ist nicht diese eindeutige, gerätegebundene ID. Sie wird
von Windows auf Grund bestimmter Kriterien gebildet. Am Ende des von
PNPDeviceID gelieferten Strings hängt zwar eine Zeichenfolge, die man
möglicherweise als ID interpretieren könnte. Aber:
- man weiß nicht, woher Windows diese Zeichenfolge nimmt. Jedenfalls
entspricht sie nicht den von der USB-org geforderten Kriterien.
- sie ist auch nicht geräteabhängig und für das Gerät eindeutig, da die
PNPDeviceID für das gleiche Gerät auf unterschiedlichen Rechnern
unterschiedlich ist. Damit kann es nicht die von mir gesuchte ID sein.
- nach dem Beitrag von Peter ist sie sogar gleich für mehrere Geräte,
wenn sie von der gleichen Art sind (gleicher Hersteller, gleicher Typ).
Anbei noch der Code in lauffähiger Form:
<module1_code>
'******************************************************************************
'* Types, consts and vars
'******************************************************************************
Public Type TInfo
InfoName As String
InfoValue As Variant
ParName() As String
ParVals() As Variant
ParCount As Long
End Type
Public gInfo() As TInfo
Public gInfoCount As Long
'******************************************************************************
'* WMI
'******************************************************************************
Public Sub gWMIDriveInfo()
Dim WMI
Dim Drives, Drive
Dim Partitions, Partition
Dim LogicalDisks, LogicalDisk
Dim s As String
ClearInfo
Set WMI = GetObject("winmgmts:")
Set Drives = WMI.InstancesOf("Win32_DiskDrive")
For Each Drive In Drives
s = Replace$(Drive.DeviceID, "\", "\\", 1, -1, vbTextCompare)
s = "ASSOCIATORS OF " & _
"{Win32_DiskDrive.DeviceID=""" & s & """}" & _
"WHERE AssocClass = Win32_DiskDriveToDiskPartition"
Set Partitions = WMI.ExecQuery(s)
For Each Partition In Partitions
s = "ASSOCIATORS OF " & _
"{Win32_DiskPartition.DeviceID=""" & Partition.DeviceID & """}" & _
"WHERE AssocClass = Win32_LogicalDiskToPartition"
Set LogicalDisks = WMI.ExecQuery(s)
For Each LogicalDisk In LogicalDisks
AddInfo "Drive letter", UCase$(Left$(LogicalDisk.DeviceID, 1))
AddParam "Drive Caption", Drive.Caption
AddParam "Drive DeviceID", Drive.DeviceID
AddParam "Drive PNPDeviceID", Drive.PNPDeviceID
AddParam "Drive InterfaceType", Drive.InterfaceType
AddParam "Disk PNPDeviceID", LogicalDisk.PNPDeviceID
AddParam "Disk DriveType", LogicalDisk.DriveType
AddParam "Disk VolumeName", LogicalDisk.VolumeName
AddParam "Disk VolumeSerialNumber", LogicalDisk.VolumeSerialNumber
Next
Next
Next
SortInfo
End Sub
'******************************************************************************
'* Collection info items helpers
'******************************************************************************
Private Sub AddInfo(ByVal InfoName As String, ByVal InfoValue As Variant)
ReDim Preserve gInfo(0 To gInfoCount)
gInfo(gInfoCount).InfoName = InfoName
gInfo(gInfoCount).InfoValue = InfoValue
gInfoCount = gInfoCount + 1
End Sub
Private Sub AddParam(ByVal Name As String, ParamArray Pars() As Variant)
With gInfo(gInfoCount - 1)
ReDim Preserve .ParName(0 To .ParCount)
ReDim Preserve .ParVals(0 To .ParCount)
.ParName(.ParCount) = Name
Select Case UBound(Pars)
Case 0
.ParVals(.ParCount) = Pars(0)
Case Is > 0
.ParVals(.ParCount) = Pars
End Select
.ParCount = .ParCount + 1
End With
End Sub
Private Sub ClearInfo()
Erase gInfo
gInfoCount = 0
End Sub
Private Sub SortInfo()
If gInfoCount > 0 Then QSortInfo 0, gInfoCount - 1
End Sub
Private Sub QSortInfo(ByVal l As Long, _
ByVal h As Long)
Dim LP As Long, HP As Long
Dim t As TInfo, PIV As Variant
PIV = gInfo((l + h) \ 2).InfoValue: LP = l: HP = h
Do
While (gInfo(LP).InfoValue < PIV): LP = LP + 1: Wend
While (PIV < gInfo(HP).InfoValue): HP = HP - 1: Wend
If LP <= HP Then
If LP < HP Then t = gInfo(LP): gInfo(LP) = gInfo(HP): gInfo(HP) = t
LP = LP + 1: HP = HP - 1
End If
Loop While (LP <= HP)
If HP > l Then QSortInfo l, HP
If LP < h Then QSortInfo LP, h
End Sub
</module1_code>
<module2_code>
Private Type TByte
Items(0 To 7) As Byte
End Type
Private Type TInt
Items(0 To 3) As Integer
End Type
Private Type TLong
Items(0 To 1) As Long
End Type
Private Type TCurrency
Item As Currency
End Type
Private Const mcBARLEN As Long = 80
Private Const mcDESCLEN As Long = 30
Public gOut As TextBox
'******************************************************************************
'* Misc helpers
'******************************************************************************
Public Function gToHex(ByVal v As Variant) As String
Dim tb As TByte, ti As TInt, tl As TLong, tc As TCurrency
Dim l As Long, i As Long, s(0 To 7) As String
Select Case VarType(v)
Case vbInteger
ti.Items(0) = v: LSet tb = ti: l = 2
Case vbLong
tl.Items(0) = v: LSet tb = tl: l = 4
Case vbCurrency
tc.Item = v: LSet tb = tc: l = 8
End Select
For i = l - 1 To 0 Step -1
s(7 - i) = Hex$(tb.Items(i))
If Len(s(7 - i)) = 1 Then s(7 - i) = "0" & s(7 - i)
Next i
gToHex = "&H" & Join$(s, vbNullString)
End Function
'******************************************************************************
'* Print helper
'******************************************************************************
Public Sub gPInfo(ByVal Title As String)
Dim i As Long, n As Long
gPH Title
For i = 0 To gInfoCount - 1
With gInfo(i)
gP .InfoName, .InfoValue
For n = 0 To .ParCount - 1
gP .ParName(n), .ParVals(n)
Next n
End With
gP ""
gP String$(mcBARLEN, "-")
gP ""
Next i
End Sub
Public Sub gPH(ByVal Msg As String)
gP String$(mcBARLEN, "*")
gP "* " & Msg
gP String$(mcBARLEN, "*")
gP ""
End Sub
Public Sub gPC()
gOut.Text = vbNullString
End Sub
Public Sub gP(ByVal Msg As String, ParamArray Pars() As Variant)
Dim s As String, v As Variant, vv As Variant
gOut.SelStart = Len(gOut.Text)
If UBound(Pars) >= 0 Then
If Len(Msg) < mcDESCLEN Then Msg = Msg & Space$(mcDESCLEN - Len(Msg))
For Each v In Pars
If VarType(v) >= vbArray Then
For Each vv In v
s = s & vv & ", "
Next vv
Else
s = s & v & ", "
End If
Next v
gOut.SelText = Msg & ": " & Left$(s, Len(s) - 2) & vbCrLf
Else
gOut.SelText = Msg & vbCrLf
End If
End Sub
</module2_code>
<form1_code>
'1 button cmdGo, 1 multiline textbox txtOut
Private Sub Form_Load()
Set gOut = txtOut
End Sub
Private Sub cmdGo_Click()
gWMIDriveInfo
gPInfo "WMI (Windows Management Instrumentation) Drive Info"
End Sub
</form1_code>
Ulrich Korndoerfer
Peter Götz schrieb:
> ...
> Ich habe hier einige solcher Speichersticks von div. Herstellern mit WMI
> untersucht.
> Eine eindeutige Seriennummer habe ich leider bei keinem gefunden. Der Wert
> war jeweils NULL.
Welchen Code hast Du denn verwendet? Reicht ohne "Verzierungen".
> PNPDeviceID und div. andere mit WMI lesbare IDs unterscheiden sich hier nur
> bei Sticks verschiedener Hersteller. Bei unterschiedlichen Sticks des
> gleichen Herstellers waren alle IDs, die ich bisher mit WMI untersuchen
> konnte, gleich oder eben NULL. Unterschiede konnte ich nur bei Sticks
> unterschiedlicher Hersteller feststellen.
>
> Hast Du eine genaue Spezifikation, welche beschreibt, welche der vielen IDs
> Du genau suchst?
USB.org, "Mass storage class", usbmassbulk_10.pdf:
Chapter "4 Standard Descriptors"
The device shall support the following standard USB descriptors:
· Device. Each USB device has one device descriptor (per USB Specification).
· Configuration. Each USB device has one default configuration
descriptor, which supports at least one
interface.
· Interface. The device shall support at least one interface, known
herein as the Bulk-Only Data
Interface. Some devices may support additional interfaces, to provide
other capabilities.
· Endpoint. The device shall support the following endpoints, in
addition to the default pipe that is
required of all USB devices:
(a) Bulk-In endpoint
(b) Bulk-Out endpoint
Some devices may support additional endpoints, to provide other
capabilities. The host shall use the
first reported Bulk-In and Bulk-Out endpoints for the selected interface.
· String. The device shall supply a unique serial number as detailed in
4.1.1 - Serial Number.
Chapter "4.1 Device descriptor"
Each USB device has one device descriptor (per USB Specification). The
device shall specify the device class
and subclass codes in the interface descriptor, and not in the device
descriptor.
Table 4.1 - Device Descriptor
Offset Field Size Value Description
0 bLength Byte 12h Size of this descriptor in bytes.
1 bDescriptorType Byte 01h DEVICE descriptor type.
2 bcdUSB Word ????h USB Specification Release Number in Binary-Coded Decimal
(i.e. 2.10 = 210h). This field identifies the release of the USB
Specification with which the device and is descriptors are
compliant.
4 bDeviceClass Byte 00h Class is specified in the interface descriptor.
5 bDeviceSubClass Byte 00h Subclass is specified in the interface
descriptor.
6 bDeviceProtocol Byte 00h Protocol is specified in the interface
descriptor.
7 bMaxPacketSize0 Byte ??h Maximum packet size for endpoint zero. (only
8, 16, 32, or 64
are valid (08h, 10h, 20h, 40h)).
8 idVendor Word ????h Vendor ID (assigned by the USB-IF).
10 idProduct Word ????h Product ID (assigned by the manufacturer).
12 bcdDevice Word ????h Device release number in binary-coded decimal.
14 iManufacturer Byte ??h Index of string descriptor describing the
manufacturer.
15 iProduct Byte ??h Index of string descriptor describing this product.
16 iSerialNumber Byte ??h Index of string descriptor describing the
device’s serial number.
(Details in 4.1.1 below)
17 bNumConfigurations Byte ??h Number of possible configurations.
NOTE: Information in this table is from the USB Specification version
1.1 table 9-7. Bold text has been
added for clarifications when using these descriptors with this
specification.
Chapter "4.1.1 Serial Number"
The iSerialNumber field shall be set to the index of the string
descriptor that contains the serial number. The
serial number shall contain at least 12 valid digits, represented as a
UNICODE string. The last 12 digits of the
serial number shall be unique to each USB idVendor and idProduct pair.
The host may generate a globally unique identifier by concatenating the
16 bit idVendor, the 16 bit idProduct
and the value represented by the last 12 characters of the string
descriptor indexed by iSerialNumber.
The field iSerialNumber is an index to a string descriptor and does not
contain the string itself. An example
format for the String descriptor is shown below.
Table 4.2 - Example Serial Number Format
Offset Field Size Value Description
0 bLength Byte ??h Size of this descriptor in bytes - Minimum of 26 (1Ah)
1 bDescriptorType Byte 03h STRING descriptor type
2 wString1 Word 00??h Serial number character 1
4 wString2 Word 00??h Serial number character 2
6 wString3 Word 00??h Serial number character 3
: : Word : :
: : Word : :
n x 2 wStringn Word 00??h Serial number character n
Shall be at least 12 characters long
Chapter "4.1.2 Valid Serial Number Characters"
The following table defines the valid characters that the device shall
use for the serial number.
Table 4.3 - Valid Serial Number Characters
Numeric ASCII
0030h through 0039h "0" through "9"
0041h through 0046h "A" through "F"
Ok, ich stell das mal unter http://www.prosource.de/Temp/usb.pdf zur
Verfügung.
Ulrich Korndoerfer
Das Originaldokument ist zu finden unter:
http://www.usb.org/developers/devclass_docs#approved
Auf dieser Seite unter dem Link betitelt mit: "Mass Storage Bulk Only 1.0"
Oder direkt mit:
http://www.usb.org/developers/devclass_docs/usbmassbulk_10.pdf
Ich ziehe die Kopie auf www.prosource.de/Temp wieder ein!
Thorsten Albers
> Danke. Muß ich mal ausprobieren (Deinen Code). Die Meinungen, wie man
> Festplattendaten ausliest, gehen auseinander, sobald es darum geht, dies
> unabhängig von der OS-Version und der Hardware zu tun. Entweder mit
> IOCTL_STORAGE_QUERY_PROPERTY oder mit dem von Dir beschriebenen Weg.
>
> In beiden Fällen ist aber mE nicht zu erwarten, daß ich damit die von
> mir gesuchte ID bekomme.
Das meinte ich auch gar nicht! Es ging mir nur darum, anhand dieses
Beispiels das Prinzip der Kommunikation mit einem Treiber über
DeviceIoControl() darzustellen, da Du schriebest, Dir wäre das
Parameter-Handling nicht so ganz klar.
Wenn Du einen entsprechenden USB-Treiber gefunden hast, welchen Du mit
CreateFile() 'öffnen' kannst, dann sollte die Treiber-Kommunikation so
durchzuführen sein, wie in den S.M.A.R.T.-Beispielen gezeigt. Voraussetzung
ist, daß Du die entsprechenden Treiber-Kommando-Codes hast und ihre
Parameter dokumentiert sind. Über die direkte Kommunikation mit dem Treiber
sollten alle Möglichkeiten des 'Betriebenen' ausgenutzt werden können.
Gestattet der Treiber nicht das Auslesen der von Dir gewünschten ID, gibt
es auch keine andere Möglichkeit, diese zu erhalten.
Vielleicht habe ich Dich aber auch nur mißverstanden?
Ulrich Korndoerfer
Microsoft's USB FAQ - Intermediate von:
http://www.microsoft.com/whdc/system/bus/USB/USBFAQ_intermed.mspx
What characters or bytes are valid in a USB serial number?
A USB device has two choices for storing serial numbers in the
iSerialNumber field (in the USB device descriptor):
•
iSerialNumber == 0x00 : The USB device has no serial number.
•
iSerialNumber != 0x00 : The USB device has a serial number and it is
stored at the string index indicated in iSerialNumber.
If the device has a serial number, Microsoft requires that the serial
number uniquely identify each instance of the same device. For example,
if two device descriptors have identical values for the idVendor,
idProduct, and bcdDevice fields, the iSerialNumber field will
distinguish one from the other.
Windows Plug and Play requires that serial numbers across multiple buses
follow specified rules. Every byte in a USB serial number is checked for
correctness. If a single invalid byte is found, the serial number is
discarded and the device is treated as if it had no serial number.
Invalid bytes in serial numbers are indicated below:
•
Byte values less than 0x20 are invalid.
•
Byte values greater than 0x7F are invalid.
•
Byte value 0x2C is invalid.
For additional details on the iSerialNumber field, see Section 9.6.1 of
the USB 2.0 specification, which is available from the USB website at
http://www.usb.org/developers/docs This link leaves the Microsoft.com site.
Damit fordert MS:
- Wenn eine Serial vorhanden ist, dann muß sie für jedes physische Gerät
gleichen Typs (Typ gekennzeichnet durch VID,PID etc) eindeutig sein.
- Es kann aber auch keine da sein. Allerdings ist bei MS allgemein von
USB devices die Rede, und eben nicht im speziellen von mass storage
devices. Die USB specs im allgemeinen (siehe
http://www.usb.org/developers/docs/usb_20_02212005.zip und darin
usb_20.pdf, Abschnitt 9.6.1, in dem der Aufbau eines device descriptors
definiert wird) fordern nicht, daß eine Serial vorhanden ist. Bei mass
storage devices aber wird ein Vorhandensein gefordert.
- Und MS akzeptiert einen erweiterten Zeichensatz (alle druckbaren
ASCII-Zeichen außer 0x2C) gegenüber dem von usb.org geforderten (nur "0"
- "9" und "A" bis "F").
In den usb-specs wird immer von "shall" geredet. Und "shall" hat
kontextabhängig neben "soll" auch die Bedeutung "muß". Nach meiner
Interpretation fordert die usb-spec das Vorhandensein einer serial (bei
mass storage devices, zu denen die USB-Sticks ja gehören). Das
verhindert zwar nicht, daß sich ein Hersteller nicht daran hält, aber
gegen ein "muß" werden doch nicht *alle* Hersteller sich trauen, dagegen
zu verstoßen. Mit anderen Worten: es sollte ;-) mass storage devices da
draussen geben, die eine Serial haben. Man muß solche Geräte nur finden
:-). Und dazu muß man die Serial erst mal zweifelsfrei auslesen können.
Uwe Sieber
Ulrich Korndoerfer wrote:
> A USB device has two choices for storing serial numbers in the
> iSerialNumber field (in the USB device descriptor):
> •
>
> iSerialNumber == 0x00 : The USB device has no serial number.
> •
>
> iSerialNumber != 0x00 : The USB device has a serial number and it is
> stored at the string index indicated in iSerialNumber.
Ah - das kommt mir bekannt vor. Schau Dir mal das MS-Programm
'USB View' an - das gibts mit C-Quellen im DDK. Und tatsächlich
hat mein Stick eine iSerial = 0x03. War mir nie aufgefallen,
weil USB View hier nicht ganz zu Ende programmiert ist - es
beläßt es beim Anzeigen des Offets...
Gruß Uwe
Uwe Sieber
> 'USB View' an - das gibts mit C-Quellen im DDK. Und tatsächlich
> hat mein Stick eine iSerial = 0x03. War mir nie aufgefallen,
> weil USB View hier nicht ganz zu Ende programmiert ist - es
> beläßt es beim Anzeigen des Offets...
Hab gerade ein neuere Version gefunden - die zeigt die
Serial sogar an. Fehlen nur noch die Quellen...
http://www.redcl0ud.com/files/USBView.cab
Gruß Uwe
Uwe Sieber
Uwe Sieber wrote:
> Hab gerade ein neuere Version gefunden - die zeigt die
> Serial sogar an. Fehlen nur noch die Quellen...
> http://www.redcl0ud.com/files/USBView.cab
Nicht die Quellen von Microsofts Tool sondern eines
von Intel - ist aber alles drin was man braucht:
http://www.intel.com/intelpress/usb/examples/DUSBVC.PDF
Gruß Uwe
Peter Götz
> Das Originaldokument ist zu finden unter:
>
> http://www.usb.org/developers/devclass_docs#approved
>
> Auf dieser Seite unter dem Link betitelt mit: "Mass Storage Bulk Only 1.0"
>
> Oder direkt mit:
>
> http://www.usb.org/developers/devclass_docs/usbmassbulk_10.pdf
>
> Ich ziehe die Kopie auf www.prosource.de/Temp wieder ein!
Werde ich mir heute mal genauer ansehen, da ich auch schon seit einiger Zeit
(bisher leider vergeblich) nach einer "eindeutigen" ID für solche
Memorysticks suche.
Peter Götz
> Noch ein Nachtrag
>
> Microsoft's USB FAQ - Intermediate von:
>
> http://www.microsoft.com/whdc/system/bus/USB/USBFAQ_intermed.mspx
>
> What characters or bytes are valid in a USB serial number?
>
> A USB device has two choices for storing serial numbers in the
> iSerialNumber field (in the USB device descriptor):
> •
>
> iSerialNumber == 0x00 : The USB device has no serial number.
> •
>
> iSerialNumber != 0x00 : The USB device has a serial number and it is
> stored at the string index indicated in iSerialNumber.
Ich weiss (noch) nicht so recht, wie ich die mit WMI ausgelesenen Nummern
bzw. IDs mit der hier genannten iSerialNumber zusammenbringe. Im USB device
descriptor, so wie ich ihn mit WMI ausgelesen habe, habe ich keine
Eindeutigkeit erkennen können. Auch hier waren die zu findenden Nummern zwar
bei Sticks unterschiedlicher Hersteller verschieden, nicht aber bei Sticks
gleicher Speichergrösse und gleicher Modellbezeichnung des selben
Herstellers.
Ich werde das heute mal auf einem Rechner probieren, bei dem ich mehrere
gleiche Sticks gleichzeitig stecken kann und melde mich dann nochmal mit dem
dabei verwendeten WMI-Code.
Ulrich Korndoerfer
Uwe Sieber schrieb:
Besser ist DUSBVC.zip (VC Projekt mit den Projekt und Sourcefiles). Die
PDF-Variante enthält nur die Cpp Sourcen. Leider fehlen mir hier die
drei Headerfiles "usbioctl.h", "stdio.h" und "stdlib.h".
Noch besser: DUSBVB.zip enthält ein VB Projekt! Dazu braucht man noch
die drei Module aus COMMVB.zip und schon hat man ein VB Programm zum
Anzeigen der USB Device descriptors. Leider funktionierts bei mir nicht
(immer wenn ich auf einen der grünen Buttons drücke, bekomme ich nur
Fehlermeldungen). Muß mal sehen, was da los ist.
Unter http://www.intel.com/intelpress/usb/examples/download.htm kann man
sich (fast) alles holen. Es empfiehlt sich, die zip Dateien aus der
Spalte "Download ZipFile" zu holen.
COMMVB.zip gibts auf
http://www.intel.com/intelpress/usb/examples/ZipFiles/commVB.htm
Ulrich Korndoerfer
Peter Götz schrieb:
> ...
> Werde ich mir heute mal genauer ansehen, da ich auch schon seit einiger Zeit
> (bisher leider vergeblich) nach einer "eindeutigen" ID für solche
> Memorysticks suche.
Prima! Dann können wir ja gemeinsam suchen.
Ulrich Korndoerfer
Peter Götz schrieb:
> ...
> Ich werde das heute mal auf einem Rechner probieren, bei dem ich mehrere
> gleiche Sticks gleichzeitig stecken kann und melde mich dann nochmal mit dem
> dabei verwendeten WMI-Code.
Und ich werde mal den VB-Code aus den Beispielen zu dem Intelbuch "USB
Design by Example" überarbeiten (den Code aus DUSBVB.zip und
COMMVB.zip). Der hat das wirklich nötig ;-). Mal sehen, ob ich dann den
Fehler finden kann.
Ulrich Korndoerfer
Thorsten Albers schrieb:
> ...
> Das meinte ich auch gar nicht! Es ging mir nur darum, anhand dieses
> Beispiels das Prinzip der Kommunikation mit einem Treiber über
> DeviceIoControl() darzustellen, da Du schriebest, Dir wäre das
> Parameter-Handling nicht so ganz klar.
> Wenn Du einen entsprechenden USB-Treiber gefunden hast, welchen Du mit
> CreateFile() 'öffnen' kannst, dann sollte die Treiber-Kommunikation so
> durchzuführen sein, wie in den S.M.A.R.T.-Beispielen gezeigt. Voraussetzung
> ist, daß Du die entsprechenden Treiber-Kommando-Codes hast und ihre
> Parameter dokumentiert sind. Über die direkte Kommunikation mit dem Treiber
> sollten alle Möglichkeiten des 'Betriebenen' ausgenutzt werden können.
> Gestattet der Treiber nicht das Auslesen der von Dir gewünschten ID, gibt
> es auch keine andere Möglichkeit, diese zu erhalten.
Ist schon klar.
Bei Deinem S.M.A.R.T.-Beispiel für DFP_RECEIVE_DRIVE_DATA fehlen mir ein
paar Werte für:
- DFP_RECEIVE_DRIVE_DATA
- bIDCmd (bzw. IDCMD bei meinem Code)
und die Angaben darüber, wie der Rückgabebuffer aufgebaut ist. Könntest
Du das nachliefern? Ich hab das DDK Kit leider nicht.
Mein Nachbau (zum Üben) sieht zZt so aus:
'Declarations and types for gDICSMARTDriveInfo
'Original: ByRef lpSecurityAttributes As SECURITY_ATTRIBUTES
Private Declare Function CreateFile Lib "kernel32.dll" Alias
"CreateFileA" ( _
ByVal lpFileName As String, _
ByVal dwDesiredAccess As Long, _
ByVal dwShareMode As Long, _
ByVal lpSecurityAttributes As Long, _
ByVal dwCreationDisposition As Long, _
ByVal dwFlagsAndAttributes As Long, _
ByVal hTemplateFile As Long) As Long
Private Const GENERIC_READ As Long = &H80000000
Private Const GENERIC_WRITE As Long = &H40000000
Private Const FILE_SHARE_READ As Long = &H1
Private Const FILE_SHARE_WRITE As Long = &H2
Private Const OPEN_EXISTING As Long = 3
Private Declare Function CloseHandle Lib "kernel32.dll" (ByVal hObject
As Long) As Long
'Original: ByRef lpOverlapped As OVERLAPPED
Private Declare Function DeviceIoControl Lib "kernel32.dll" ( _
ByVal hDevice As Long, _
ByVal dwIoControlCode As Long, _
ByRef lpInBuffer As Any, _
ByVal nInBufferSize As Long, _
ByRef lpOutBuffer As Any, _
ByVal nOutBufferSize As Long, _
ByRef lpBytesReturned As Long, _
ByVal lpOverlapped As Long) As Long
Private Const IDENTIFY_BUFFER_SIZE As Long = 512
Private Type TIDEREGS
bFeaturesReg As Byte '01 Used for specifying SMART
"commands".
bSectorCountReg As Byte '02 IDE sector count register
bSectorNumberReg As Byte '03 IDE sector number register
bCylLowReg As Byte '04 IDE low order cylinder value
bCylHighReg As Byte '05 IDE high order cylinder value
bDriveHeadReg As Byte '06 IDE drive/head register
bCommandReg As Byte '07 Actual IDE command.
bReserved As Byte '08 reserved for future use. Must
be zero.
End Type
Private Type TSENDCMDINPARAMS
lBufferSize As Long ' 04 TSENDCMDOUTBUF (!!!) size in bytes
IRDRIVEREGS As TIDEREGS ' 12 Structure with drive register
values.
bDeviceNumber As Byte ' 13 Physical drive number to send
command to (0,1,2,3).
abReserved(0 To 2) As Byte ' 16 Reserved for future expansion.
alReserved(0 To 3) As Long ' 32 For future use.
End Type
Private Type TSENDCMDINBUF
B(0 To IDENTIFY_BUFFER_SIZE - 1) As Byte
End Type
Private Type TSENDCMDINPARAMS_WITHBUF
Param As TSENDCMDINPARAMS
InBuf As TSENDCMDINBUF
End Type
Private Type TDRIVERSTATUS
bDriverError As Byte ' 01 Error code from driver, or 0
if no error.
bIDEStatus As Byte ' 02 Contents of IDE Error register.
' Only valid when bDriverError is
SMART_IDE_ERROR.
bReserved(0 To 1) As Byte ' 04 Reserved for future expansion.
alReserved(0 To 1) As Long ' 12 Reserved for future expansion.
End Type
Private Type TSENDCMDOUTPARAMS
lBufferSize As Long '04 Size of OutBuf in bytes
DRIVERSTATUS As TDRIVERSTATUS '16 Driver status structure.
End Type
Private Type TSENDCMDOUTBUF
B(0 To IDENTIFY_BUFFER_SIZE - 1) As Byte
End Type
Private Type TSENDCMDOUTPARAMS_WITHBUF
Param As TSENDCMDOUTPARAMS
OutBuf As TSENDCMDOUTBUF ' Buffer of arbitrary
length in which
End Type ' to store the data
read from the drive
Public Sub gDICSMARTDriveInfo()
Const IDCMD As Byte = &HEC 'Wert?
Const DFP_RECEIVE_DRIVE_DATA As Long = &H7C088 'Wert? Identisch zu
SMART_RCV_DRIVE_DATA in ntdddisk.h?
Const cMaxDeviceCount As Long = 8
'Für WIN98: \\.\SMARTVSD ohne Nummer
Const cDEVICENAME As String = "\\.\PhysicalDrive%1"
Dim SCIP() As TSENDCMDINPARAMS
Dim SCOP() As TSENDCMDOUTPARAMS_WITHBUF
Dim OutBuf As TSENDCMDOUTBUF
Dim DevName As String, ResDIC As Long, BytesReturned As Long
Dim DevNum As Long, hSmart As Long
ReDim SCIP(0 To 0)
ReDim SCOP(0 To 0)
Do
DevName = Replace$(cDEVICENAME, "%1", CStr(DevNum))
With SCIP(0)
.lBufferSize = Len(OutBuf)
With .IRDRIVEREGS
.bSectorCountReg = 1
.bSectorNumberReg = 1
.bDriveHeadReg = &HA0 Or ((DevNum And 1) * (2 ^ 4)) 'Physical
drive number (0, 1, 2 etc)
.bCommandReg = IDCMD
End With
.bDeviceNumber = DevNum
End With
hSmart = CreateFile(DevName, _
(GENERIC_READ Or GENERIC_WRITE), _
(FILE_SHARE_READ Or FILE_SHARE_WRITE), _
0, _
OPEN_EXISTING, _
0, _
0)
If hSmart <> 0 Then
ResDIC = DeviceIoControl(hSmart, _
DFP_RECEIVE_DRIVE_DATA, _
SCIP(0), _
Len(SCIP(0)), _
SCOP(0), Len(SCOP(0)), _
BytesReturned, _
0)
CloseHandle hSmart
If ResDIC <> 0 And BytesReturned <> 0 Then
'Rückgabe-Daten aus SCOP(0).OutBuf auslesen. Wie?
End If
End If
DevNum = DevNum + 1
Loop Until DevNum >= cMaxDeviceCount
End Sub
Der Code läuft und in SCOP(0).OutBuf steht auch was drin. Ich habe die
Input und Outputbuffer in ein Array gesteckt, damit der Speicher dafür
im Heap angelegt wird (das wird ja von DeviceIoControl verlangt).
Erwartungsgemäß erhalte ich für die gewöhnlichen HD drives ein Handle in
hSmart, für die anderen (USB sticks und drives) nicht (sind wohl nicht
SMART genug :-)).
Ansonsten konzentriere ich momentan auf den Code von Intel (siehe auch
den Post an Peter).
Peter Götz
> Prima! Dann können wir ja gemeinsam suchen.
Ich habe gestern mit nachfolgendem Code verschiedene Sticks (2 vom gleichen
Hersteller mit gleicher Speichergrösse (Stick1 u. Stick2, einen weiteren von
einem anderen Hersteller (JetFlash) getestet.
Public Sub ShowSticks()
Dim wmiServices As Object
Dim wmiDiskDrives As Object
Dim wmiDiskDrive As Object
Dim wmiDiskPartitions As Object
Dim wmiDiskPartition As Object
Dim wmiLogicalDisks As Object
Dim wmiLogicalDisk As Object
Dim strEscapedDeviceID As String
Set wmiServices = GetObject("winmgmts:")
Set wmiDiskDrives = wmiServices.InstancesOf("Win32_DiskDrive")
For Each wmiDiskDrive In wmiDiskDrives
Debug.Print "Disk drive Caption: " & wmiDiskDrive.Caption & _
vbCrLf & "DeviceID: " & wmiDiskDrive.DeviceID & _
vbCrLf & "PNPDeviceID: " & wmiDiskDrive.PNPDeviceID
strEscapedDeviceID = Replace(wmiDiskDrive.DeviceID, _
"\", "\\", 1, -1,
vbTextCompare)
Set wmiDiskPartitions = _
wmiServices.ExecQuery("ASSOCIATORS OF " & _
"{Win32_DiskDrive.DeviceID=""" & _
strEscapedDeviceID & """} WHERE " & _
"AssocClass = Win32_DiskDriveToDiskPartition")
For Each wmiDiskPartition In wmiDiskPartitions
Set wmiLogicalDisks = _
wmiServices.ExecQuery("ASSOCIATORS OF " & _
"{Win32_DiskPartition.DeviceID=""" &
wmiDiskPartition.DeviceID & _
"""} WHERE AssocClass = Win32_LogicalDiskToPartition")
For Each wmiLogicalDisk In wmiLogicalDisks
Debug.Print "Properties_.(VolumeName): " & _
wmiLogicalDisk.Properties_("VolumeName").Value
Debug.Print "Properties_.(ValumeSerialNumber): " & _
wmiLogicalDisk.Properties_("VolumeSerialNumber").Value
Debug.Print "Properties_.PNPDeviceID: " & _
wmiLogicalDisk.PNPDeviceID
Debug.Print "wmiLogicalDisk.Qualifiers_(UUID).Value : " & _
wmiLogicalDisk.Qualifiers_("UUID").Value
Next
Next
Debug.Print vbCrLf
Next
End Sub
'***********************
Und das sind die Ergebnisse, welche leider keine einem
bestimmten Stick eindeutig zuzuordnende ID zeigen.
_____________________________________________
Stick1 alleine gesteckt:
Disk drive Caption: USB 2.0 Flash Disk USB Device
DeviceID: \\.\PHYSICALDRIVE5
PNPDeviceID: USBSTOR\DISK&VEN_USB_2.0&PROD_FLASH_DISK&REV_2.00\6&1F96E902&0
Properties_.(VolumeName): STICK1
Properties_.(VolumeSerialNumber): AC9FC7D4
Properties_.PNPDeviceID:
wmiLogicalDisk.Qualifiers_(UUID).Value :
{8502C4B7-5FBB-11D2-AAC1-006008C78BC7}
_____________________________________________
Stick2 alleine gesteckt:
Disk drive Caption: USB 2.0 Flash Disk USB Device
DeviceID: \\.\PHYSICALDRIVE5
PNPDeviceID: USBSTOR\DISK&VEN_USB_2.0&PROD_FLASH_DISK&REV_2.00\6&35BE51BF&0
Properties_.(VolumeName): STICK2
Properties_.(VolumeSerialNumber): 80902222
Properties_.PNPDeviceID:
wmiLogicalDisk.Qualifiers_(UUID).Value :
{8502C4B7-5FBB-11D2-AAC1-006008C78BC7}
_____________________________________________
Stick1 und Stick2 gemeinsam gesteckt:
Disk drive Caption: USB 2.0 Flash Disk USB Device
DeviceID: \\.\PHYSICALDRIVE5
PNPDeviceID: USBSTOR\DISK&VEN_USB_2.0&PROD_FLASH_DISK&REV_2.00\7&34D6BEB7&0
Properties_.(VolumeName): STICK1
Properties_.(VolumeSerialNumber): AC9FC7D4
Properties_.PNPDeviceID:
wmiLogicalDisk.Qualifiers_(UUID).Value :
{8502C4B7-5FBB-11D2-AAC1-006008C78BC7}
Disk drive Caption: USB 2.0 Flash Disk USB Device
DeviceID: \\.\PHYSICALDRIVE6
PNPDeviceID: USBSTOR\DISK&VEN_USB_2.0&PROD_FLASH_DISK&REV_2.00\7&221D0E12&0
Properties_.(VolumeName): STICK2
Properties_.(VolumeSerialNumber): 80902222
Properties_.PNPDeviceID:
wmiLogicalDisk.Qualifiers_(UUID).Value :
{8502C4B7-5FBB-11D2-AAC1-006008C78BC7}
_______________________________________________
Stick1 und Stick2 vom gleichen Hersteller und
Stick eines anderen Herstellers gesteckt:
Disk drive Caption: JetFlash TS128MJF2A USB Device
DeviceID: \\.\PHYSICALDRIVE7
PNPDeviceID: USBSTOR\DISK&VEN_JETFLASH&PROD_TS128MJF2A&REV_1.00\6&146FE573&0
Properties_.(VolumeName):
Properties_.(VolumeSerialNumber): 32000000
Properties_.PNPDeviceID:
wmiLogicalDisk.Qualifiers_(UUID).Value :
{8502C4B7-5FBB-11D2-AAC1-006008C78BC7}
Disk drive Caption: USB 2.0 Flash Disk USB Device
DeviceID: \\.\PHYSICALDRIVE6
PNPDeviceID: USBSTOR\DISK&VEN_USB_2.0&PROD_FLASH_DISK&REV_2.00\7&221D0E12&0
Properties_.(VolumeName): STICK2
Properties_.(VolumeSerialNumber): 80902222
Properties_.PNPDeviceID:
wmiLogicalDisk.Qualifiers_(UUID).Value :
{8502C4B7-5FBB-11D2-AAC1-006008C78BC7}
Disk drive Caption: USB 2.0 Flash Disk USB Device
DeviceID: \\.\PHYSICALDRIVE5
PNPDeviceID: USBSTOR\DISK&VEN_USB_2.0&PROD_FLASH_DISK&REV_2.00\7&34D6BEB7&0
Properties_.(VolumeName): STICK1
Properties_.(VolumeSerialNumber): AC9FC7D4
Properties_.PNPDeviceID:
wmiLogicalDisk.Qualifiers_(UUID).Value :
{8502C4B7-5FBB-11D2-AAC1-006008C78BC7}
____________________________________
Keine der gelieferten Nummern und/oder GUIDs ist eindeutig einem bestimmten
Stick zuzuordnen.
Ich werde mir nachher auch mal die Beispiele von Intel genauer ansehen, in
der Hoffnung dass man damit etwas weiter kommt.
Peter Götz
> Noch besser: DUSBVB.zip enthält ein VB Projekt! Dazu braucht man noch
> die drei Module aus COMMVB.zip und schon hat man ein VB Programm zum
> Anzeigen der USB Device descriptors. Leider funktionierts bei mir nicht
> (immer wenn ich auf einen der grünen Buttons drücke, bekomme ich nur
> Fehlermeldungen). Muß mal sehen, was da los ist.
An diesem Ding bin ich auch gerade dran und versuche mal aus diesem Chaos
halbwegs lesbaren Programmcode zu machen.
Nachdem ich Option Explicit eingefügt und dutzende von
Variablendeklarationen ergänzt habe, lässt sich das Programm immerhin
starten. Beim Drücken des Buttons "Host Controller 0" hagelt es
Fehlermeldungen. Drücken des Buttons "Host Controller 1" endet in einem
Totalabsturz.
Insgesamt macht dieses Programm eher den Eindruck, dass sich hierbei jemand
grösste Mühe gegeben hat, möglichst unlesbaren Code zu schreiben.
Ulrich Korndoerfer
Peter Götz schrieb:
>> Noch besser: DUSBVB.zip enthält ein VB Projekt! Dazu braucht man noch
Der Autor (das Buch kenne ich nicht) hat wahrscheinlich Ahnung von USB
und kann (wahrscheinlich) C programmieren. Mit VB allerdings hat er aber
auch gar nichts am Hut. Der Code ist das haarsträubendste, was mir seit
langem untergekommen ist.
Dennoch, ich habe ihn inzwischen bereinigt: ByVal/ByRef
Parameterübergabe korrigiert, Option Explicit eingeschaltet und alle
Vars deklariert, die Dimensionsangaben für Arrays auf sauber gestellt,
Überflüssiges rausgeworfen (zB Abhängigkeit von der apigid32.dll und das
HID-Modul), Funktionalität zusammengefasst, das Codebild optisch
verbessert, die Formularaufrufe und generell die ganze innere
Ablauflogik auf feste Füsse gestellt, etc. pp.
Ergebnis: ich komme bis zu den grünen Knöpfen. Drücken darf ich sie
auch, dann erscheint in der Listbox ein Root-Hub mit Ports, die alle
leer sind (keine Devices angeschlossen). Wird der Root-Hub angeklickt
(in der Listbox), erscheint die (leider leere) Datenanzeigeform.
Bei den Kernroutinen im USB-Modul kommen mir einige
DeviceIoControl-Aufrufe merkwürdig vor. Leider kann ich nicht
nachprüfen, ob die Parameter, so wie verwendet, richtig sind. Die
Controlcodes für die DeviceIoControl-Aufrufe sind nämlich direkt als
Hexparameter angegeben. Somit kenne ich deren Namen nicht und bin
aufgeschmissen.
In welchem Headerfile müßte ich denn da nachsehen? Habe aber das DDK-Kit
nicht.
Ich werde heute oder morgen noch ein bißchen dran basteln, mal sehen,
was dabei rauskommt. Den aktuellen Stand gibts unter:
http://www.proSource.de/Temp/DUSVB_Refactored.zip
Zu der WMI-Geschichte: die UUID ist nicht geräteabhängig, die
charakterisiert eine WMI-Klasse. Ich verwende fast den gleichen Code wie
Du. Habe noch eine Automatik eingebaut, die alle Properties einer
WMI-Klasse anzeigt.
Habe dazu eine Wrapperanwendung geschrieben, mit der man mit
verschiedenen Methoden Hardwaredaten auslesen und gegeneinander
vergleichen kann.
Für Interessierte zu haben unter:
http://www.proSource.de/Temp/Test_ReadHardwareData.zip
Aber Vorsicht! Das ist alles ziemlich experimentell. Anwendung nur auf
eigene Gefahr!
Uwe Sieber
Ulrich Korndoerfer wrote:
> Bei den Kernroutinen im USB-Modul kommen mir einige
> DeviceIoControl-Aufrufe merkwürdig vor. Leider kann ich nicht
> nachprüfen, ob die Parameter, so wie verwendet, richtig sind. Die
> Controlcodes für die DeviceIoControl-Aufrufe sind nämlich direkt als
> Hexparameter angegeben. Somit kenne ich deren Namen nicht und bin
> aufgeschmissen.
>
> In welchem Headerfile müßte ich denn da nachsehen? Habe aber das DDK-Kit
> nicht.
usbioctl.h
Dort werden sie über ein Macro zusammengebastelt.
Ich habe die Konstanten einfach mal in der Reihenfolge in der
sie im VC Beispielprojekt auftauchen in Hex ausgeben lassen -
vielleicht hilft dir das:
IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION
IOCTL_USB_GET_NODE_CONNECTION_INFORMATION
IOCTL_USB_GET_NODE_CONNECTION_NAME
IOCTL_USB_GET_NODE_INFORMATION
IOCTL_GET_HCD_DRIVERKEY_NAME
IOCTL_USB_GET_ROOT_HUB_NAME
220410
22040c
220414
220408
220424
220408
IOCTL_USB_GET_NODE_INFORMATION und IOCTL_USB_GET_ROOT_HUB_NAME haben
wirklich den gleichen Wert.
Gruß Uwe
Uwe Sieber
Ulrich Korndoerfer wrote:
>>> Noch besser: DUSBVB.zip enthält ein VB Projekt!
Übrigens sind vier Buttons etwas knapp: Aktuelle Intel-
Chipsätze haben z.B. 8 USB-Ports. Die erscheinen jeweils
in einer USB 1.1 und einer 2.0 Inkarnation:
Vier USB 1.1 Root-Hubs mit je zwei Ports (HCD0 bis HCD3)
und ein USB 2.0 Root-Hub mit 8 Ports (HCD4). Einfach mal
mit USB View ansehen.
USB2-Geräte erscheinen am 2.0-Root-Hub - da reichen die
vier Buttons nicht, wenn der USB2-Root-Hub 'hinten liegt'.
Mich würde interessieren, wie man ermittelt, welcher USB 1.1
und 2.0 Port jeweils zusammen auf einem physischen Port
liegt. Wird wohl nicht gehen...
Gruß Uwe
Ulrich Korndoerfer
Uwe Sieber schrieb:
>
> Ulrich Korndoerfer wrote:
>
>>>> Noch besser: DUSBVB.zip enthält ein VB Projekt!
>
> Übrigens sind vier Buttons etwas knapp: Aktuelle Intel-
> Chipsätze haben z.B. 8 USB-Ports. Die erscheinen jeweils
> in einer USB 1.1 und einer 2.0 Inkarnation:
> Vier USB 1.1 Root-Hubs mit je zwei Ports (HCD0 bis HCD3)
> und ein USB 2.0 Root-Hub mit 8 Ports (HCD4). Einfach mal
> mit USB View ansehen.
>
> USB2-Geräte erscheinen am 2.0-Root-Hub - da reichen die
> vier Buttons nicht, wenn der USB2-Root-Hub 'hinten liegt'.
Die Buttons sind für die Hostcontroller. 4 Buttons - 4 Hostcontroller.
Von da ab hangelt sich das Programm dann über Hubs und Ports zu den
Devices weiter (zumindest sollte es das, tut aber bei mir noch nicht).
> Mich würde interessieren, wie man ermittelt, welcher USB 1.1
> und 2.0 Port jeweils zusammen auf einem physischen Port
> liegt. Wird wohl nicht gehen...
Weiß ich leider auch nicht.
Ulrich Korndoerfer
Uwe Sieber schrieb:
> ...
Ja, genau diese Werte werden im Programm verwendet. Das sit schon mal gut.
Jetzt fehlt mir nur noch die Doku. Mein PlattformSDK scheint schon etwas
veraltet zu sein ;-)
Reichen für dies USB Geschichten ein aktuelles PlattformSDK oder brauche
ich das DDK?
Uwe Sieber
>> Übrigens sind vier Buttons etwas knapp: Aktuelle Intel-
>> Chipsätze haben z.B. 8 USB-Ports. Die erscheinen jeweils
>> in einer USB 1.1 und einer 2.0 Inkarnation:
>> Vier USB 1.1 Root-Hubs mit je zwei Ports (HCD0 bis HCD3)
>> und ein USB 2.0 Root-Hub mit 8 Ports (HCD4). Einfach mal
>> mit USB View ansehen.
>>
>> USB2-Geräte erscheinen am 2.0-Root-Hub - da reichen die
>> vier Buttons nicht, wenn der USB2-Root-Hub 'hinten liegt'.
>
> Die Buttons sind für die Hostcontroller. 4 Buttons - 4 Hostcontroller.
> Von da ab hangelt sich das Programm dann über Hubs und Ports zu den
> Devices weiter (zumindest sollte es das, tut aber bei mir noch nicht).
Ja, klar. Aber an jedem Hostcontroller hängt genau ein
Root-Hub. Habe ich zumindest noch nie anders gesehen.
Hier ein USB-View Screenshot vom Onboard-USB eines i915:
http://www.uwe-sieber.de/temp/usbview_i915.gif
Hier hat Deine Fassung des Programms übrigens funktioniert -
hat also alle Ports gefunden und korrekt angezeigt 'No device'
oder 'IO device connected'. Auch mein Corsair-Stick mit
seinem merkwürdigen integrierten Ein-Port-Hub wurde korrekt
ermittelt.
Gruß Uwe
Uwe Sieber
> Ja, genau diese Werte werden im Programm verwendet. Das sit schon mal gut.
>
> Jetzt fehlt mir nur noch die Doku. Mein PlattformSDK scheint schon etwas
> veraltet zu sein ;-)
>
> Reichen für dies USB Geschichten ein aktuelles PlattformSDK oder brauche
> ich das DDK?
DDK macht sich gut wg. der Header und LIBs. Dokumentiert ist
da längst nicht alles.
--------------
Zitat von http://www.lvr.com/usbfaq.htm
How can I determine which port my device is attached to?
You can obtain the driver key from a device using SetupDi
functions, and obtain the same key from a hub port using
undocumented DeviceIoControl codes.
--------------
Ist also kein Wunder, wenn man bei MS nicht fündig wird...
Gruß Uwe
Peter Götz
> > Ah - das kommt mir bekannt vor. Schau Dir mal das MS-Programm
> > 'USB View' an - das gibts mit C-Quellen im DDK. Und tatsächlich
> > hat mein Stick eine iSerial = 0x03. War mir nie aufgefallen,
> > weil USB View hier nicht ganz zu Ende programmiert ist - es
> > beläßt es beim Anzeigen des Offets...
USB View zeigt bei mir für einen CardReader die iSerialNumber 0x03
Eindeutigkeit ist mit dieser Nummer also nicht wirklich gegeben.
6 verschiedene USB-MemorySticks von 3 verschiedenen Herstellern haben laut
USB View bei mir alle iSerialNumber = 0x00
Es verdichtet sich mehr und mehr die Einsicht, dass es bei diesen Sticks
keine wirklich eindeutige Identifikationsmöglichkeit gibt.
Stefan Koschke
"Ulrich Korndoerfer" <ulrich_wa...@prosource.de> schrieb im
Newsbeitrag news:43E79331...@prosource.de...
> Hallo Peter!
>
> Prima! Dann können wir ja gemeinsam suchen.
>
suchst Du eigentlich in die richtige Richtung? ;-)
Ich habe den inzwischen ziemlich langen Thread mal überflogen und
festgestellt, daß Du die Serial für Lizenzierungszwecke benötigst.
Soll das heißen, Du willst einen USB-Stick wie einen Dongle verwenden?
Wenn ja wäre ja nun eigentlich überlegenswert, einen "echten" Dongle zu
verwenden, so wie z.B. die von MatrixLock die ich einsetze:
Die kosten etwa das gleiche wie der kleinste USB-Stick, haben eine
problemlos auslesbare eindeutige Seriennummer, zusätzlich noch 60 Byte die
Du selbst beschreiben kannst, 128 Bit-Verschlüsselung und wenn Du gar keine
Arbeit haben willst, kannst Du mit der mitgelieferten Software Dein Programm
mit dem Dongle so verschlüsseln lassen, daß es nur noch startet wenn der
Dongle steckt. Dafür ist z.B. überhaupt kein Programmieraufwand
erforderlich!
Ciao
Stefan
Thorsten Albers
<usVr4eK...@TK2MSFTNGP11.phx.gbl>...
> USB View zeigt bei mir für einen CardReader die iSerialNumber 0x03
> Eindeutigkeit ist mit dieser Nummer also nicht wirklich gegeben.
Der Wert 0x03 in iSerialNumber ist nicht etwa die Seriennummer selbst,
sondern vielmehr ein sog. string descriptor index, der in die Tabelle der
von dem USB-Gerät zur Verfügung gestellten Strings verweist. Weitere
derartartige Indizes sind "iManufacturer", "iProduct", "iConfiguration" und
"iInterface".
> 6 verschiedene USB-MemorySticks von 3 verschiedenen Herstellern haben
laut
> USB View bei mir alle iSerialNumber = 0x00
Mein PNY Attaché USB-Stick liefert korrekte Strings für "Product" und
"SerialNumber" und einen Leerstring für "Manufacturer". "Configuration" und
"Interface" sind 'unbesetzt.
Wir können ja 'mal versuchen, hier eine kleine Liste zu erstellen,
gewissermaßen als Kauftipp für diese Art der Verdongelung. Wichtig ist
dafür ja nicht, daß es USB-Sticks gibt, die keine Seriennummer etc. haben,
sondern welche, die eine solche haben. Da man den Dongel überlicherweise
mit dem Programm liefert, kann man dann ja anhand dieser Liste selbst einen
kaufen.
Also:
ID ID IManufac IPro ISerial
Product Vendor turer duct Number
PNY X X - X X
Attaché
Uwe Sieber
Ulrich Korndoerfer wrote:
> Ergebnis: ich komme bis zu den grünen Knöpfen. Drücken darf ich sie
> auch, dann erscheint in der Listbox ein Root-Hub mit Ports, die alle
> leer sind (keine Devices angeschlossen).
Hast Du zufällig Windows 2000? Dann sieht das Programm
nur USB 1.1, s. http://support.microsoft.com/?kbid=838100
Gruß Uwe
Ulrich Korndoerfer
Thorsten Albers schrieb:
> Peter Götz <gssg_...@t-online.de> schrieb im Beitrag
> <usVr4eK...@TK2MSFTNGP11.phx.gbl>...
>> USB View zeigt bei mir für einen CardReader die iSerialNumber 0x03
>> Eindeutigkeit ist mit dieser Nummer also nicht wirklich gegeben.
>
> Der Wert 0x03 in iSerialNumber ist nicht etwa die Seriennummer selbst,
> sondern vielmehr ein sog. string descriptor index, der in die Tabelle der
> von dem USB-Gerät zur Verfügung gestellten Strings verweist. Weitere
> derartartige Indizes sind "iManufacturer", "iProduct", "iConfiguration" und
> "iInterface".
>
So ist es.
>> 6 verschiedene USB-MemorySticks von 3 verschiedenen Herstellern haben
> laut
>> USB View bei mir alle iSerialNumber = 0x00
>
> Mein PNY Attaché USB-Stick liefert korrekte Strings für "Product" und
> "SerialNumber" und einen Leerstring für "Manufacturer". "Configuration" und
> "Interface" sind 'unbesetzt.
>
Du hast einen Diplomatenstick? Vielleicht ist das ja eine
Sonderanfertigung für das Auswärtige Amt? Kein Wunder, daß er dann eine
Seriennummer hat.
> Wir können ja 'mal versuchen, hier eine kleine Liste zu erstellen,
> gewissermaßen als Kauftipp für diese Art der Verdongelung. Wichtig ist
> dafür ja nicht, daß es USB-Sticks gibt, die keine Seriennummer etc. haben,
> sondern welche, die eine solche haben. Da man den Dongel überlicherweise
> mit dem Programm liefert, kann man dann ja anhand dieser Liste selbst einen
> kaufen.
> Also:
>
> ID ID IManufac IPro ISerial
> Product Vendor turer duct Number
> PNY X X - X X
> Attaché
>
Ich würde ja mitarbeiten an der Tabelle. Leider habe ich dieses USB-View
nicht. Wo ist das denn lauffertig (kompiliert) zu haben?
Übrigens sind die Kreuze in der Tabghelle ziemlich witzlos. Den
USB-Stick sollte man nicht nur anhand des Namens, sondern auch schon
anhand der PID, VID etc identifizieren können. Warum gibst Du sie nicht an?
Ulrich Korndoerfer
Uwe Sieber schrieb:
>
> Hier hat Deine Fassung des Programms übrigens funktioniert -
> hat also alle Ports gefunden und korrekt angezeigt 'No device'
> oder 'IO device connected'. Auch mein Corsair-Stick mit
> seinem merkwürdigen integrierten Ein-Port-Hub wurde korrekt
> ermittelt.
Ach nee, das is ja gediegen ;-)
Hmm, und Du hast nichts daran geändert? Und wenn ein Device vorhanden
war, konntest Du auch (mit der zweiten Form/Fenster) dessen device
descriptors incl. der serial (die serial selbst, nicht bloß den Index)
auslesen?
Ulrich Korndoerfer
Stefan Koschke schrieb:
> suchst Du eigentlich in die richtige Richtung? ;-)
>
> Ich habe den inzwischen ziemlich langen Thread mal überflogen und
> festgestellt, daß Du die Serial für Lizenzierungszwecke benötigst.
> Soll das heißen, Du willst einen USB-Stick wie einen Dongle verwenden?
>
> Wenn ja wäre ja nun eigentlich überlegenswert, einen "echten" Dongle zu
> verwenden, so wie z.B. die von MatrixLock die ich einsetze:
>
> Die kosten etwa das gleiche wie der kleinste USB-Stick, haben eine
> problemlos auslesbare eindeutige Seriennummer, zusätzlich noch 60 Byte die
> Du selbst beschreiben kannst, 128 Bit-Verschlüsselung und wenn Du gar keine
> Arbeit haben willst, kannst Du mit der mitgelieferten Software Dein Programm
> mit dem Dongle so verschlüsseln lassen, daß es nur noch startet wenn der
> Dongle steckt. Dafür ist z.B. überhaupt kein Programmieraufwand
> erforderlich!
Mhm, wenn ich auf deren Website (wieder mal) nachsehe, dann kostet
dieser Dongle in Einzelstückzahlen (immer noch) ca. 36 Euro (incl.
MwSt). Das ist bei weitem der teuerste Dongle, den ich kenne. Einen 64
MB USB-Stick bekommt man in Einzelstückzahl für unter 10 Euro. Damit
kann man ein Lizensierungsverfahren aufbauen, welches völlig individuell
ist (im Gegensatz zu einem, welches schon längst gecrackt sein kann,
und Spielregeln vorgibt, die mir vielleicht nicht liegen).
Im Klartext:
Dongles bieten zuwenig fürs Geld. Sie sind unflexibel und lassen keine
Abweichung vom durch den Dongle vorgegebenen Lizensierungsverfahren zu,
wenn man "automatischen" Schutz ohne viel Eigenarbeit haben will. Will
man dagegen einen sicheren, nicht 08/15- Schutz, muß man auch beim
herkömmlichen Dongle selbst Hand anlegen.
Ulrich Korndoerfer
Uwe Sieber schrieb:
> Hast Du zufällig Windows 2000? Dann sieht das Programm
> nur USB 1.1, s. http://support.microsoft.com/?kbid=838100
WIN2K, SP4. Auch der Rechner hatte ursprünglich nur USB1.1 ports (auf
dem Motherboard). Ist inzwischen aber mit einer UBS2.0 PCI-Karte
aufgerüstet, incl. den zugehörigen Treibern.
Frank Landen
Am Mon, 6 Feb 2006 11:46:02 +0100 schrieb Peter Götz:
> Werde ich mir heute mal genauer ansehen, da ich auch schon seit einiger Zeit
> (bisher leider vergeblich) nach einer "eindeutigen" ID für solche
> Memorysticks suche.
Ich hänge mich auch mit rein, suche auch schon ewig.... bisher diente mir
halt nur die "Partitions"-Nummer. Mal zerpflüpcken, was die bei Intel so
anbieten.... echt grausam.
Grüße
Frank
Ulrich Korndoerfer
> Mhm, wenn ich auf deren Website (wieder mal) nachsehe, dann kostet
> dieser Dongle in Einzelstückzahlen (immer noch) ca. 36 Euro (incl.
> MwSt). ...
Das war der Preis für die LPT Version. Die USB Version des MLU-60 kostet
39 Euro. Preise haben die, ts,ts
Frank Landen
Am Wed, 08 Feb 2006 17:41:09 +0100 schrieb Ulrich Korndoerfer:
> Nachtrag
>
>> Mhm, wenn ich auf deren Website (wieder mal) nachsehe, dann kostet
>> dieser Dongle in Einzelstückzahlen (immer noch) ca. 36 Euro (incl.
>> MwSt). ...
>
> Das war der Preis für die LPT Version. Die USB Version des MLU-60 kostet
> 39 Euro. Preise haben die, ts,ts
Jip... ich setze seit geraumer Zeit immer noch auf Wibu-Teile... rund 70
Möpse fürn USB-Dongle. Unverschämt teuer.
Darum ist der Thread hier ein sehr interessanter Denkanstoss, den ich
eigentlich im Geiste auch schon länger vorhatte, aber mich nie so richtig
durch gerungen hatte.
Aber nun bin ich voll dabei und kämpfe mich durch.
Grüße
Frank
Peter Götz
> Ich würde ja mitarbeiten an der Tabelle. Leider habe ich dieses USB-View
> nicht. Wo ist das denn lauffertig (kompiliert) zu haben?
http://www.redcl0ud.com/files/USBView.cab
Thorsten Albers
<43EA1C09...@prosource.de>...
> Du hast einen Diplomatenstick? Vielleicht ist das ja eine
> Sonderanfertigung für das Auswärtige Amt? Kein Wunder, daß er dann eine
> Seriennummer hat.
Hua, hua, hua... Ich gehe bei dem Namen eher von einer tyüisch
fernöstlichen Vermengung von französisch "Attaché" und englisch "to attach"
aus. Letzteres würde m.E. bei einem USB-Stick weit mehr Sinn machen.
> > Wir können ja 'mal versuchen, hier eine kleine Liste zu erstellen,
> > gewissermaßen als Kauftipp für diese Art der Verdongelung. Wichtig ist
> > dafür ja nicht, daß es USB-Sticks gibt, die keine Seriennummer etc.
haben,
> > sondern welche, die eine solche haben. Da man den Dongel
überlicherweise
> > mit dem Programm liefert, kann man dann ja anhand dieser Liste selbst
einen
> > kaufen.
> > Also:
> >
> > ID ID IManufac IPro ISerial
> > Product Vendor turer duct Number
> > PNY X X - X X
> > Attaché
> >
>
> Ich würde ja mitarbeiten an der Tabelle. Leider habe ich dieses USB-View
> nicht. Wo ist das denn lauffertig (kompiliert) zu haben?
Ich habe sie nicht mit UBS View ermittelt, sondern mit eigenen VB-Code, den
ich unter Rückgriff auf den Quellcode von USB View geschrieben habe bzw.
gerade schreibe. Ich hoffe, heute abend damit fertig zu sein, dann stelle
ich ihn in's Netz zur allgemeinen Verfügung. Näheres dann dazu später.
> Übrigens sind die Kreuze in der Tabghelle ziemlich witzlos. Den
> USB-Stick sollte man nicht nur anhand des Namens, sondern auch schon
> anhand der PID, VID etc identifizieren können. Warum gibst Du sie nicht
an?
Nein, wieso? Die Tabelle soll ja nur eine Hilfe für den Interessierten sein
zu erfahren, welche USB-Sticks mit einer Seriennummer etc. kommen, damit er
das nicht selbst durch Kauf ausprobieren muß - das einzige, was er im
Voraus wissen muß. Sobald er den Stick hat, muß er die Daten ja sowieso
selbst auslesen.
Die Voraussetzung für eine Nutzung als Dongle ist m.E. die Lieferung von
IDVendor
+ IDProduct
+ ISerialNumber,
woraus ich dann eine Dongle-ID
VVVV-PPPP-<Serien-Nr.>
zusammensetzen würde mit VVVV und PPPP als vierstelliger Hexadezimal-ID und
der Serien-Nr. wie geliefert.
Uwe Sieber
Ulrich Korndoerfer wrote:
>> Hier hat Deine Fassung des Programms übrigens funktioniert -
>> hat also alle Ports gefunden und korrekt angezeigt 'No device'
>> oder 'IO device connected'. Auch mein Corsair-Stick mit
>> seinem merkwürdigen integrierten Ein-Port-Hub wurde korrekt
>> ermittelt.
>
> Ach nee, das is ja gediegen ;-)
>
> Hmm, und Du hast nichts daran geändert?
Nein, nur ein paar Buttons mehr.
> Und wenn ein Device vorhanden
> war, konntest Du auch (mit der zweiten Form/Fenster) dessen device
> descriptors incl. der serial (die serial selbst, nicht bloß den Index)
> auslesen?
Ja, auch da tut sich was:
http://www.uwe-sieber.de/temp/usb1.gif
Die iSerial=0x04 steht da. Wo soll den die Serial
stehen - hab jetzt keine Lust zum nachsehen...
Gruß Uwe
Frank Landen
Am Thu, 02 Feb 2006 02:48:34 +0100 schrieb Ulrich Korndoerfer:
> weiß jemand, wie man aus einem handelsüblichen USB-Massenspeicher
> (USB-Memorystick) die Seriennummer auslesen kann?
>
> Gemeint ist damit die eindeutige, nicht nachträglich änderbare
> Seriennummer, die der Hersteller des Sticks dem USB-Controller (neben
> VID,PID etc) verpaßt.
>
Unter folgenden Registry-Eintrag sind doch auch alle Geräte aufgelistet
nach Vendor- und ProductID. Direkt unter dem dementsprechenden Gerät steht
auch die Seriennummer, wenn ich mich nicht irre.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB
Noch ein wenig Lesestoff:
http://www.usb.org/phpbb/viewtopic.php?t=4623&postdays=0&postorder=asc&start=0
Grüsse
Frank
Ulrich Korndoerfer
Uwe Sieber schrieb:
> ...
>> Und wenn ein Device vorhanden
>> war, konntest Du auch (mit der zweiten Form/Fenster) dessen device
>> descriptors incl. der serial (die serial selbst, nicht bloß den Index)
>> auslesen?
>
> Ja, auch da tut sich was:
> http://www.uwe-sieber.de/temp/usb1.gif
> Die iSerial=0x04 steht da. Wo soll den die Serial
> stehen - hab jetzt keine Lust zum nachsehen...
Unten ist eine Klapprunterliste. Da drin :-) Das GUI von dem Ding müßte
mal überarbeitet werden :-)
Klappt jetzt auch bei mir, zumindest auf meinem Laptop. Der hat USB2.0
Hardware von Haus aus, läuft aber auch unter WIN2K.
Und siehe da, ein Stick (von den zweien, die ich habe) hat eine serial!
Der andere nicht. Wenn ich mir dann die PNPDeviceID der WMI WIN32_Drive
Klasse ansehe, wird offensichtlich die serial des Sticks, der eine
serial hat, in die PNPDeviceID mit aufgenommen (als letzter Bestandteil
hinter dem letzten Backslash. Bei dem Stick ohne serial steht da auch
was, aber offensichtlich von Windows aus dem hohlen Bauch heraus ohne
einen Bezug zu einer serial (logischerweise, da nicht vorhanden)
erzeugt. Die spannende Frage ist nun, ob, wenn eine serial vorhanden
ist, diese immer von Windows in die PNPDeviceID aufgenommen wird, und
sie von dort immer auf die gleiche Art und Weise parsebar ist.
Die Serial sieht so aus (mit DUSBVB gelesen):
SNDK8D7AC433BEB07904
Die serial erfüllt alle MS Kriterien.
Die PNPDeviceID ist:
USBSTOR\DISK&VEN_SANDISK&PROD_CRUZERMINI&REV_0.2\SNDK8D7AC433BEB07904&0
Ulrich Korndoerfer
Thorsten Albers schrieb:
Ok, aber dann wäre zumindes eine etwas genauere Angabe des Sticks
hilfreich. Nur Attache ist etwas wenig. Zumindest den Herstellernamen
und eine genauere Produktbezeichnung, die Speicherkapazität und evtl.
die Kaufquelle und den Preis.
Mein Stick:
SanDisk Cruzer Mini, 1 GB, MediaMarkt, ca. 70 E (vor einem Jahr)
> Die Voraussetzung für eine Nutzung als Dongle ist m.E. die Lieferung von
> IDVendor
> + IDProduct
> + ISerialNumber,
> woraus ich dann eine Dongle-ID
> VVVV-PPPP-<Serien-Nr.>
> zusammensetzen würde mit VVVV und PPPP als vierstelliger Hexadezimal-ID und
> der Serien-Nr. wie geliefert.
>
--
Ulrich Korndoerfer
Peter Götz schrieb:
>> Ich würde ja mitarbeiten an der Tabelle. Leider habe ich dieses USB-View
>> nicht. Wo ist das denn lauffertig (kompiliert) zu haben?
>
> http://www.redcl0ud.com/files/USBView.cab
Oh je, 'ne Hackerseite :-) (redcl0ud mit Null statt Oh). Na dann, Augen
zu und durch :-)
Frank Landen
Am Thu, 02 Feb 2006 02:48:34 +0100 schrieb Ulrich Korndoerfer:
> weiß jemand, wie man aus einem handelsüblichen USB-Massenspeicher
> (USB-Memorystick) die Seriennummer auslesen kann?
>
> Gemeint ist damit die eindeutige, nicht nachträglich änderbare
> Seriennummer, die der Hersteller des Sticks dem USB-Controller (neben
> VID,PID etc) verpaßt.
>
Ich prüfe des gerade einmal...
Grüsse
Frank
Ulrich Korndoerfer
Uwe Sieber schrieb:
>> weiß jemand, wie man aus einem handelsüblichen USB-Massenspeicher
>> (USB-Memorystick) die Seriennummer auslesen kann?
>>
>> Gemeint ist damit die eindeutige, nicht nachträglich änderbare
>> Seriennummer, die der Hersteller des Sticks dem USB-Controller (neben
>> VID,PID etc) verpaßt.
>
> Vendor- und Product ID und die Hardware-Seriennummer bekommt
> man per DeviceIoControl und IOTL_STORAGE_QUERY_PROPERTY.
> Bei Festplatten bekommt man tatsächlich die Seriennummer -
> bei den Sticks und USB-Platten die mir bisher untergekommen
> sind, kommen zwar Vendor- und Product ID, bei SerialNumberOffset
> kommt aber immer Null, also keine Seriennummer.
Das die serial nicht immer vorhanden ist, wissen wir ja nun. Ob
IOCTL_STORAGE_QUERY_PROPERTY nun wirklich die serial aus dem
USB-devicedescriptor liest, wäre zu prüfen (durch Vergleich mit der
serial, die andere Methoden liefern).
Hast Du vielleicht ein Codebeispiel für mich (darf auch C sein)
inclusive der Deklarationen (structs, Konstante)? Danke im voraus.
Thorsten Albers
> Ok, aber dann wäre zumindes eine etwas genauere Angabe des Sticks
> hilfreich. Nur Attache ist etwas wenig. Zumindest den Herstellernamen
Wer Augen hat, der schaue: "PNY" (sic!)
> und eine genauere Produktbezeichnung,
Genauer geht's nicht, mehr gibt's nicht.
> die Speicherkapazität und evtl.
256 MB
> die Kaufquelle und den Preis.
Keine Ahnung, hab' ich geschenkt bekommen. Insg. ist aber doch eher
unwahrscheinlich, daß ein Stick des Herstellers eine SN liefert, ein
anderer Stick desselben Herstellers aber nicht.
> Mein Stick:
> SanDisk Cruzer Mini, 1 GB, MediaMarkt, ca. 70 E (vor einem Jahr)
Da warst Du wohl nicht blöd, was?
Uwe Sieber
Ulrich Korndoerfer wrote:
>> Vendor- und Product ID und die Hardware-Seriennummer bekommt
>> man per DeviceIoControl und IOTL_STORAGE_QUERY_PROPERTY.
>> Bei Festplatten bekommt man tatsächlich die Seriennummer -
>> bei den Sticks und USB-Platten die mir bisher untergekommen
>> sind, kommen zwar Vendor- und Product ID, bei SerialNumberOffset
>> kommt aber immer Null, also keine Seriennummer.
>
> Das die serial nicht immer vorhanden ist, wissen wir ja nun. Ob
> IOCTL_STORAGE_QUERY_PROPERTY nun wirklich die serial aus dem
> USB-devicedescriptor liest, wäre zu prüfen (durch Vergleich mit der
> serial, die andere Methoden liefern).
Auch bei Sticks die per USB-View eine Serial haben,
bekommt man per IOCTL_STORAGE_QUERY_PROPERTY keine.
http://www.vbarchiv.net/workshop/workshop78s3.html
http://www.winsim.com/diskid32/diskid32.cpp
http://www.codeproject.com/w2k/usbdisks.asp
Gruß Uwe
Uwe Sieber
Stefan Koschke wrote:
> suchst Du eigentlich in die richtige Richtung? ;-)
>
> Ich habe den inzwischen ziemlich langen Thread mal überflogen und
> festgestellt, daß Du die Serial für Lizenzierungszwecke benötigst.
> Soll das heißen, Du willst einen USB-Stick wie einen Dongle verwenden?
>
> Wenn ja wäre ja nun eigentlich überlegenswert, einen "echten" Dongle zu
> verwenden, so wie z.B. die von MatrixLock die ich einsetze:
Scheint mir auch die bessere Wahl zu sein, denn
das mit der USB-Stick-Seriennummer läßt sich recht
leicht aushebeln. Man nehme das MS-DDK und bastle
einen USB-Filter-Treiber, der die Serial aus einer
INI statt vom drunterliegenden Treiber meldet...
Selbst wenn man das noch nie gemacht hat, braucht
man dazu bestimmt kaum mehr Zeit als wir hier bis
zum erfolgreichen Auslesen der Nummer...
Gruß Uwe
Stefan Koschke
"Uwe Sieber" <ma...@uwe-sieber.de> schrieb im Newsbeitrag
news:450bs2F...@individual.net...
das sehe ich genau so :-)))
Und dazu sollte man auch bei der Diskussion um 36 EUR pro Einzeldongle oder
20 EUR ab 10 Stück auch nicht vergessen, daß man dabei auch die sonst
"verbratene" Zeit zur Implementierung einer USB-Stick-Seriennummer
einrechnen muß und der Stick ja auch Geld kostet!
Und morgen gibt es die billigen Sticks für 10 EUR nur noch von einem anderen
Hersteller und da funktioniert vielleicht die Seriennummer wieder nicht....
Matrix liefert umfassenden Beispielcode und die Implementierung in ein
bestehendes Programm hat bei mir ca. 1/2 Tag gedauert.
Ciao
Stefan
Ulrich Korndoerfer
Uwe Sieber schrieb:
...
>> Soll das heißen, Du willst einen USB-Stick wie einen Dongle verwenden?
>>
>> Wenn ja wäre ja nun eigentlich überlegenswert, einen "echten" Dongle zu
>> verwenden, so wie z.B. die von MatrixLock die ich einsetze:
>
> Scheint mir auch die bessere Wahl zu sein, denn
> das mit der USB-Stick-Seriennummer läßt sich recht
> leicht aushebeln. Man nehme das MS-DDK und bastle
> einen USB-Filter-Treiber, der die Serial aus einer
> INI statt vom drunterliegenden Treiber meldet...
>
> Selbst wenn man das noch nie gemacht hat, braucht
> man dazu bestimmt kaum mehr Zeit als wir hier bis
> zum erfolgreichen Auslesen der Nummer...
Ganz so einfach, wie Du dir das vorstellst, ist es nun doch nicht.
Wie immer bei Lizenzierungsverfahren geht es darum, die Umgehung
desselben möglichst schwer zu machen. Knacksicher dürfte kein Verfahen
sein, speziell dann, wenn es den User nicht zu sehr gängeln will.
Ok, der Stick wird per Fingerprint identifiziert. Dazu gehören PID, VID,
iManufacturer, iProduct, iSerial, die VolumeNumber, die
Speicherkapazität des Sticks und mehr.
Dieser Fingerprint wird individuell für jeden Stick vor der Auslieferung
übermittelt. Diese Info kommt ins Programm und verschlüsselt in einer
Datei auf den Stick. Damit ist eine Kopie des Programmes und ein
physikalischer Stick miteinander verbunden. Eine andere Kopie ist
miteinem anderen physikalischen Stick verbunden. Wer den Stick
herstellt, ist egal, da kann man wechseln.
Zudem werden auch (zb randomisierte) Daten auf den USB-Stick geschrieben
und von dort wieder gelesen. Dann kann man noch Dateien schreiben und
wieder löschen und dann nachsehen, ob sie noch da sind.
Um jetzt dem Programm per Täuschung die korrekten Hardwaredaten und die
korrekte Datei zu liefern und auch noch das Filesystem zu simulieren
(Dateien schreiben, lesen und löschen), müßte man sich schon ziemlich
tief einklinken. Zudem kommt noch, daß man ja nicht nur mit dem
USB-Treibern arbeitet, sondern möglichst viele APis verwendet.
Und, falls dann das zB auf einer Hackerseite angeboten werden sollte,
müßte es unter allen vom Programm unterstützten Betriebssystemen laufen.
Außerdem müßte die Hackerseite auch noch das Programm mit zur Verfügung
stellen, da ja jeweils eine Kopie des Programmes nur mit einem
bestimmten Stick läuft.
Ich bin mir ziemlich sicher, daß für einen gewöhnlichen Hacker da nichts
zu machen ist.
Der klassische Weg ist ja eher, in das Programm selbst einzudringen.
Damit kann man ein Programm (jedes Programm) knacken. Nur die
Problematik hat man auch mit jedem beliebigen kommerziellen Dongle. Auch
der ist nur sicher, wen man *im* Programm selbst "mitdenkt" und für
hohen Schutz sorgt. Und dazu muß man einiges an Aufwand treiben. Und den
muß man treiben, egal ob man einen kommerziellen Dongle oder etwas
anderes verwendet. Dagegen ist der Zusatzaufwand, um ein paar USB-Daten
auszulesen, eher vernachlässigbar.
Nur die von den Dongle-Herstellern angebotenen Schnellschutzmethoden,
die wenig oder gar keinen Eingriff in das Programm erfordern, zu
verwenden, ist meines Erachtens sträflicher Leichtsinn.
Thorsten Albers
<450bs2F...@individual.net>...
> Scheint mir auch die bessere Wahl zu sein, denn
> das mit der USB-Stick-Seriennummer läßt sich recht
> leicht aushebeln. Man nehme das MS-DDK und bastle
> einen USB-Filter-Treiber, der die Serial aus einer
> INI statt vom drunterliegenden Treiber meldet...
>
> Selbst wenn man das noch nie gemacht hat, braucht
> man dazu bestimmt kaum mehr Zeit als wir hier bis
> zum erfolgreichen Auslesen der Nummer...
Auch für Dongles gibt es Software- bzw. Hardware-Emulatoren. Da in jedem
Fall die Identifizierung von der Hardware in den Speicher kommen muß, gibt
es dabei immer Angriffspunkte.
Stefan Koschke
"Ulrich Korndoerfer" <ulrich_wa...@prosource.de> schrieb im
Newsbeitrag news:43EB2CBE...@prosource.de...
> Hallo Uwe,
>
> Uwe Sieber schrieb:
>
> ...
>>> Soll das heißen, Du willst einen USB-Stick wie einen Dongle verwenden?
>>>
>>> Wenn ja wäre ja nun eigentlich überlegenswert, einen "echten" Dongle zu
>>> verwenden, so wie z.B. die von MatrixLock die ich einsetze:
>>
>> Scheint mir auch die bessere Wahl zu sein, denn
>> das mit der USB-Stick-Seriennummer läßt sich recht
>> leicht aushebeln. Man nehme das MS-DDK und bastle
>> einen USB-Filter-Treiber, der die Serial aus einer
>> INI statt vom drunterliegenden Treiber meldet...
>>
>> Selbst wenn man das noch nie gemacht hat, braucht
>> man dazu bestimmt kaum mehr Zeit als wir hier bis
>> zum erfolgreichen Auslesen der Nummer...
>
> Ganz so einfach, wie Du dir das vorstellst, ist es nun doch nicht.
>
> Wie immer bei Lizenzierungsverfahren geht es darum, die Umgehung desselben
> möglichst schwer zu machen. Knacksicher dürfte kein Verfahen sein,
> speziell dann, wenn es den User nicht zu sehr gängeln will.
>
schnipp
(Riesenaufwand beschrieben)
schnapp
wenn ich das so lese, willst Du für jeden USB-Stick ein eigenes Programm
erzeugen und den USB-Stick jeweils mit speziellen Daten befüttern?
Da hast Du ja definitiv mehr Zeit pro Lizenz verbraten als ein Dongle kostet
;-)
Sieh Dir mal die Seite von Matrixlock genau an, ich bin immer noch der
meinung, daß dies die einfacherer, kostengünstigere und sicherere
Alternative zu Deinem Vorhaben ist.
Nutze die 128 Bit-Verschlüsselung (die auch nicht aushebelbar ist) für die
Schreib/Lesefunktionen des Dongles und die 60 Byte im Dongle um ggf. auch
die Dongles für unterschiedliche Programme zu kennzeichnen.
Ciao
Stefan
Ulrich Korndoerfer
Stefan Koschke schrieb:
>>
>> Ganz so einfach, wie Du dir das vorstellst, ist es nun doch nicht.
>>
>> Wie immer bei Lizenzierungsverfahren geht es darum, die Umgehung desselben
>> möglichst schwer zu machen. Knacksicher dürfte kein Verfahen sein,
>> speziell dann, wenn es den User nicht zu sehr gängeln will.
>>
>
> schnipp
> (Riesenaufwand beschrieben)
> schnapp
>
> wenn ich das so lese, willst Du für jeden USB-Stick ein eigenes Programm
> erzeugen und den USB-Stick jeweils mit speziellen Daten befüttern?
> Da hast Du ja definitiv mehr Zeit pro Lizenz verbraten als ein Dongle kostet
> ;-)
Der Stick ist gleichzeitig das Medium, mit dem das Programm verbreitet
wird. Ergo muß das Programm auf den Stick kopiert werden (bzw. das
Setuppackage). Dabei werden automatisiert die Stickdaten ermittelt
(dient gleichzeitig der Qualitätsicherung, um auszuschließen, daß man
einen ungeeigneten Stick erwischt hat), das Lizenzfile erzeugt und die
Programmkopie personalisiert.
Wo bitte ist da der Aufwand? Stick an PC stecken, Knopf drücken, Stick
wieder abziehen, Stick in die Verkaufsverpackung des Programmes packen,
fertig.
> Sieh Dir mal die Seite von Matrixlock genau an, ich bin immer noch der
> meinung, daß dies die einfacherer, kostengünstigere und sicherere
> Alternative zu Deinem Vorhaben ist.
> Nutze die 128 Bit-Verschlüsselung (die auch nicht aushebelbar ist) für die
> Schreib/Lesefunktionen des Dongles und die 60 Byte im Dongle um ggf. auch
> die Dongles für unterschiedliche Programme zu kennzeichnen.
Ja, damit werben die Hersteller von Dongles gern: unsere Verschlüsselung
hat x Bit und ist nicht aushebelbar. Es gibt ja auch einen guten Grund,
warum die Donglehersteller immer mit ihren tollen
Verschlüsselungsverfahren (und vor allem den Bit-Längen) werben: weil
zumindest früher teilweise haarsträubende Eigenbaugeschichten verwendet
wurde. Mit Verlaub, da wird kräftig Marketingsand verstreut.
Es stehen für jedermann auch ohne Dongle leistungsfähige und nicht
knackbare Verschlüsselungsverfahren zur Verfügung. Und außerdem geht es
nicht darum, ob ein Verschlüsselungsverfahen für sich alleine knackbar
ist. Es geht um das Gesamtverfahren. Darum, wie der Schutz im Programm
umgesetzt wird. Und da ist der Aufwand gleich groß für Dongles oder
USB-Sticks.
Frank Landen
Ich schrieb:
> Ulli schrieb:
>> weiß jemand, wie man aus einem handelsüblichen USB-Massenspeicher
>> (USB-Memorystick) die Seriennummer auslesen kann?
>>
>> Gemeint ist damit die eindeutige, nicht nachträglich änderbare
>> Seriennummer, die der Hersteller des Sticks dem USB-Controller (neben
>> VID,PID etc) verpaßt.
>>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devio/base/ioctl_storage_get_media_serial_number.asp
>
> Ich prüfe des gerade einmal...
Hmm, ich bekomme die Funktion zwar aufgerufen, aber erhalte keine
brauchbaren Rückmeldungen. Ich weis nicht, ob ich "overlapped" setzen muss
oder nicht - im moment habe ich es ohne.
Ggfs poste ich den Code gerne, ist ja nicht wirklich viel.
Jedenfalls mal weiterfummeln.
Grüsse
Frank
Thorsten Albers
<43E7D8A5...@prosource.de>...
> - DFP_RECEIVE_DRIVE_DATA
> - bIDCmd (bzw. IDCMD bei meinem Code)
> und die Angaben darüber, wie der Rückgabebuffer aufgebaut ist. Könntest
> Du das nachliefern? Ich hab das DDK Kit leider nicht.
Wenn Dich die S.M.A.R.T.-Geschichte weiterhin interessiert, kann ich Dir
'mal ein uraltes Projekt von mir schicken, in welchem Du diese
Informationen findest ebenso wie einen Hinweis auf die verwendete
Dokumentation. Allerdings ist dort alles auf Windows 9x ausgelegt, für
Windows NT/XP muß es angepaßt werden - dürfte für Dich aber keine
Schwierigkeit darstellen.
Hier habe ich erst einmal ein eigenes kleines Modul zusammengeschustert,
daß USB-Informationen liefert. Auch dieses (VB 5.0(!)-)Projekt ist unter
Windows 9x entstanden, sollte aber eigentlich ohne Änderungen auch auf
NT/XP laufen - wenn es läuft...:
http://omnibus.uni-freiburg.de/~albers/snippets/usbinfo10.zip
Wer Spaß daran hat, möge damit machen, was er will. Es wäre interessant zu
erfahren, unter welcher Konfiguration es nicht läuft.
Ulrich Korndoerfer
Frank Landen schrieb:
>>>
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devio/base/ioctl_storage_get_media_serial_number.asp
>>
>> Ich prüfe des gerade einmal...
>
> Hmm, ich bekomme die Funktion zwar aufgerufen, aber erhalte keine
> brauchbaren Rückmeldungen. Ich weis nicht, ob ich "overlapped" setzen muss
> oder nicht - im moment habe ich es ohne.
>
> Ggfs poste ich den Code gerne, ist ja nicht wirklich viel.
Ja, poste doch mal. Diese Methode soll aber lt. MS nur unter WINXP
funktionieren.
Ulrich Korndoerfer
Thorsten Albers schrieb:
> Ulrich Korndoerfer <ulrich_wa...@prosource.de> schrieb im Beitrag
> <43E7D8A5...@prosource.de>...
>> - DFP_RECEIVE_DRIVE_DATA
>> - bIDCmd (bzw. IDCMD bei meinem Code)
>> und die Angaben darüber, wie der Rückgabebuffer aufgebaut ist. Könntest
>> Du das nachliefern? Ich hab das DDK Kit leider nicht.
>
> Wenn Dich die S.M.A.R.T.-Geschichte weiterhin interessiert, kann ich Dir
> 'mal ein uraltes Projekt von mir schicken, in welchem Du diese
> Informationen findest ebenso wie einen Hinweis auf die verwendete
> Dokumentation. Allerdings ist dort alles auf Windows 9x ausgelegt, für
> Windows NT/XP muß es angepaßt werden - dürfte für Dich aber keine
> Schwierigkeit darstellen.
>
Ja, Danke, wäre interessiert (verwende die im Post angegebene Emailadresse).
>
> Hier habe ich erst einmal ein eigenes kleines Modul zusammengeschustert,
> daß USB-Informationen liefert. Auch dieses (VB 5.0(!)-)Projekt ist unter
> Windows 9x entstanden, sollte aber eigentlich ohne Änderungen auch auf
> NT/XP laufen - wenn es läuft...:
>
> http://omnibus.uni-freiburg.de/~albers/snippets/usbinfo10.zip
>
> Wer Spaß daran hat, möge damit machen, was er will. Es wäre interessant zu
> erfahren, unter welcher Konfiguration es nicht läuft.
>
Bei mir (WIN2K, SP4) läufts nicht. Die Treeview für die USB Nodes bleibt
leer.
DUSVB_refactored (meine Adaption von DUSBVB) läuft dagegen.
Auf meinem Desktoprechner werden die zwei (auf dem Motherboard
vorhandenen) USB 1.1 Hostcontroller und die Ports angezeigt. Der als
PCI-Karte im Rechner vorhandene zusätzliche USB2.0 Hostcontroller und
dessen Ports wird allerdings nicht angezeigt.
Ursache dafür dürfte sein, daß die Hostcontroller unter Zuhilfename
ihrer symbolischen Namen ("\\.\HCDn") gesucht werden. Das scheint bei
meiner Konfiguration (USB1.1 auf dem Motherboard und zusätzlich USB2.0
auf einer Karte) Probleme zu machen.
MS gibt da einen Hinweis, daß in diesem Fall der USB2.0 Controller unter
dem selben symbolischen Namen wie der erste USB1.1 Controller geführt
wird und somit nicht erreichbar ist. Generell gibt es lt. MS unter WIN2K
dieses Problem, wenn sowohl ein USB1.1 als auch ein USB2.0
Hostcontroller vorhanden ist.
Abhilfe wäre, die Hostcontroller nicht über ihre symbolische Namen
sondern anders aufzulisten. Hat da jemand eine Idee?
Auf meinem Laptop (der nur einen USB2.0 Hostcontroller hat) ist dagegen
alles ok: der Controller, seine Ports und angeschlossene Devices sind
sichtbar.
Frank Landen
> Hallo Frank,
>
> Frank Landen schrieb:
>
>>>>
>>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devio/base/ioctl_storage_get_media_serial_number.asp
>>>
>>> Ich prüfe des gerade einmal...
>>
>> Hmm, ich bekomme die Funktion zwar aufgerufen, aber erhalte keine
>> brauchbaren Rückmeldungen. Ich weis nicht, ob ich "overlapped" setzen muss
>> oder nicht - im moment habe ich es ohne.
>>
>> Ggfs poste ich den Code gerne, ist ja nicht wirklich viel.
>
> Ja, poste doch mal. Diese Methode soll aber lt. MS nur unter WINXP
> funktionieren.
Type tMEDIA_SERIAL_NUMBER_DATA
SerialNumberLength As Long ' 04 Size of OutBuf in bytes
Result As Long ' 04 Error code from driver, or 0 if no
error.
alReserved(0 To 1) As Long ' 08 Reserved for future expansion.
B(256) As Byte
End Type ' to store the data read from the drive
Public Declare Function CreateFile Lib "kernel32.dll" _
Alias "CreateFileA" ( _
ByVal lpFilename As String, _
ByVal dwDesiredAccess As DESIREDFLAGS, _
ByVal dwShareMode As SHAREFLAGS, _
ByRef lpSecurityAttributes As Any, _
ByVal dwCreationDisposition As DISPOSITIONFLAGS, _
ByVal dwFlagsAndAttributes As Long, _
ByVal hTemplateFile As Long) As Long
Public Declare Function CloseHandle Lib "kernel32.dll" ( _
ByVal hObject As Long) As Long
Public Declare Function DeviceIoControl Lib "kernel32.dll" ( _
ByVal hDevice As Long, _
ByVal dwIoControlCode As IOCOMMANDS, _
ByRef lpInBuffer As Any, _
ByVal nInBufferSize As Long, _
ByRef lpOutBuffer As Any, _
ByVal nOutBufferSize As Long, _
ByRef lpBytesReturned As Long, _
ByRef lpOverlapped As Any) As Long
Public Enum DESIREDFLAGS
GENERIC_READ = &H80000000
GENERIC_WRITE = &H40000000
End Enum
Public Enum SHAREFLAGS
FILE_SHARE_READ = &H1
FILE_SHARE_WRITE = &H2
End Enum
Public Enum DISPOSITIONFLAGS
OPEN_EXISTING = 3
End Enum
Public Enum IOCOMMANDS
IOCTL_STORAGE_CHECK_VERIFY = &H2D4800
IOCTL_STORAGE_CHECK_VERIFY2 = &H2D0800
IOCTL_STORAGE_MEDIA_REMOVAL = &H2D4804
IOCTL_STORAGE_EJECT_MEDIA = &H2D4808
IOCTL_STORAGE_LOAD_MEDIA = &H2D480C
IOCTL_STORAGE_LOAD_MEDIA2 = &H2D080C
IOCTL_STORAGE_RESERVE = &H2D4810
IOCTL_STORAGE_RELEASE = &H2D4814
IOCTL_STORAGE_FIND_NEW_DEVICES = &H2D4818
IOCTL_STORAGE_EJECTION_CONTROL = &H2D0940
IOCTL_STORAGE_MCN_CONTROL = &H2D0944
IOCTL_STORAGE_GET_MEDIA_TYPES = &H2D0C00
IOCTL_STORAGE_GET_MEDIA_TYPES_EX = &H2D0C04
IOCTL_STORAGE_GET_MEDIA_SERIAL_NUMBER = &H2D0C10
IOCTL_STORAGE_GET_HOTPLUG_INFO = &H2D0C14
IOCTL_STORAGE_SET_HOTPLUG_INFO = &H2DCC18
IOCTL_STORAGE_RESET_BUS = &H2D5000
IOCTL_STORAGE_RESET_DEVICE = &H2D5004
IOCTL_STORAGE_BREAK_RESERVATION = &H2D5014
IOCTL_STORAGE_GET_DEVICE_NUMBER = &H2D1080
IOCTL_STORAGE_PREDICT_FAILURE = &H2D1100
IOCTL_STORAGE_QUERY_PROPERTY = &H2D1400
IOCTL_SCSI_PASS_THROUGH = &H4D004
IOCTL_SCSI_MINIPORT = &H4D008
IOCTL_SCSI_GET_INQUIRY_DATA = &H4100C
IOCTL_SCSI_GET_CAPABILITIES = &H41010
IOCTL_SCSI_PASS_THROUGH_DIRECT = &H4D014
IOCTL_SCSI_GET_ADDRESS = &H41018
IOCTL_SCSI_RESCAN_BUS = &H4101C
IOCTL_SCSI_GET_DUMP_POINTERS = &H41020
IOCTL_SCSI_FREE_DUMP_POINTERS = &H41024
IOCTL_IDE_PASS_THROUGH = &H4D028
End Enum
Sub Main()
Const cMaxDeviceCount As Long = 8
Const cDEVICENAME As String = "\\.\PhysicalDrive%1"
Dim DevName As String, ResDIC As Long, BytesReturned As Long
Dim DevNum As Long, hSmart As Long, Serial As String, i As Integer
Dim SCOP() As tMEDIA_SERIAL_NUMBER_DATA
ReDim SCOP(0 To 0)
Do
DevName = Replace$(cDEVICENAME, "%1", CStr(DevNum))
hSmart = CreateFile(DevName, (GENERIC_READ Or GENERIC_WRITE), _
(FILE_SHARE_READ Or FILE_SHARE_WRITE), ByVal 0&, _
OPEN_EXISTING, 0, ByVal 0&)
If hSmart <> -1 Then
ResDIC = DeviceIoControl(hSmart, _
IOCTL_STORAGE_GET_MEDIA_SERIAL_NUMBER, _
ByVal 0&, 0&, SCOP(0), Len(SCOP(0)), BytesReturned, ByVal 0&)
CloseHandle hSmart
Serial = "": i = 0 'c-string nach serial packen
Do While SCOP(0).B(i) <> 0: Serial = Serial & Chr(SCOP(0).B(i))
i = i + 2: Loop
MsgBox DevName & " " & _
Format(SCOP(0).SerialNumberLength) & " " & Serial
End If
DevNum = DevNum + 1
Loop Until DevNum >= cMaxDeviceCount
End Sub
Ich habe den Code einfach mal in einem BAS gepackt (der Ursprung war,
glaube ich von dir). Ja, es sollte nur unter XP funktionieren, glaube ich.
IOch brüte derweil einw enig über die hid.dll... irgendwo muss es doch
wirklich diese Möglichkeit geben.
Im Moment vertreibe ich meine Software auch auf einem USB-Stick.... aber
halt nur mit GetVolume-Krempel. Eine harte Serial würde mir natürlich auch
wesentlich besser gefallen.
Grüsse
Frank
Thorsten Albers
> Ja, Danke, wäre interessiert (verwende die im Post angegebene
Emailadresse).
Ist unterwegs...
> Bei mir (WIN2K, SP4) läufts nicht. Die Treeview für die USB Nodes bleibt
> leer.
> DUSVB_refactored (meine Adaption von DUSBVB) läuft dagegen.
'Mal schauen, wo der Unterschied liegt. Läuft den USB View? Mein Projekt
ist auf der Grundlage des Sourcecodes von letzterem geschrieben.
> Auf meinem Desktoprechner werden die zwei (auf dem Motherboard
> vorhandenen) USB 1.1 Hostcontroller und die Ports angezeigt. Der als
> PCI-Karte im Rechner vorhandene zusätzliche USB2.0 Hostcontroller und
> dessen Ports wird allerdings nicht angezeigt.
> Ursache dafür dürfte sein, daß die Hostcontroller unter Zuhilfename
> ihrer symbolischen Namen ("\\.\HCDn") gesucht werden. Das scheint bei
> meiner Konfiguration (USB1.1 auf dem Motherboard und zusätzlich USB2.0
> auf einer Karte) Probleme zu machen.
> MS gibt da einen Hinweis, daß in diesem Fall der USB2.0 Controller unter
> dem selben symbolischen Namen wie der erste USB1.1 Controller geführt
> wird und somit nicht erreichbar ist. Generell gibt es lt. MS unter WIN2K
> dieses Problem, wenn sowohl ein USB1.1 als auch ein USB2.0
> Hostcontroller vorhanden ist.
> Abhilfe wäre, die Hostcontroller nicht über ihre symbolische Namen
> sondern anders aufzulisten. Hat da jemand eine Idee?
Ich habe hier einen Windows 98 SE-Rechner mit 2 on-board USB 1.0-Ports und
einer USB 2.0-PCI-Karte mit 4 Ports: Dort wird alles korrekt angezeigt. Ist
dann wohl wirklich ein Probem von Windows 2000. 'Mal schauen, ob sich das
lösen läßt.
Frank Landen
[...]
>> Bei mir (WIN2K, SP4) läufts nicht. Die Treeview für die USB Nodes bleibt
>> leer.
>> DUSVB_refactored (meine Adaption von DUSBVB) läuft dagegen.
>
> 'Mal schauen, wo der Unterschied liegt. Läuft den USB View? Mein Projekt
> ist auf der Grundlage des Sourcecodes von letzterem geschrieben.
>
Bei mir läuft USBview - aber deine Umsetzung zeigt mir auch an, dass er
keine USB-Geräte findet. System: XP-SP2 und VIA-USB-Chip.
Grüsse
Frank
Thorsten Albers
<97wg37wcmidy$.lnf81f6oosvv$.d...@40tude.net>...
> Bei mir läuft USBview - aber deine Umsetzung zeigt mir auch an, dass er
> keine USB-Geräte findet. System: XP-SP2 und VIA-USB-Chip.
Möglicherweise hängt's einfach nur an den CreateFile() aufrufen:
1. (2. Parameter) Ich habe immer mit GENERIC_READ und GENERIC_WRITE
aufgerufen. GENERIC_READ müßte aber eigentlich ausreichen, da die
Parameter-Übergabe m.W. nicht unter Schreibvorgang fällt. Da GENERIC_WRITE
sicherlich andere Rechte braucht als GENERIC_READ, könnte es daran
scheitern.
2. (4. Parameter) Da ich das ganze unter Window 98 SE geschrieben habe,
habe ich keine Securit Attributes-Struktur übergeben. Auch daran könnte es
liegen.
3. (6. Parameter) Sonst wäre vielleicht auch noch mit den
'dwFlagsAndAttributes' herumzuspielen...
Ulrich Korndoerfer
Thorsten Albers schrieb:
> ...
>> Bei mir (WIN2K, SP4) läufts nicht. Die Treeview für die USB Nodes bleibt
>> leer.
>> DUSVB_refactored (meine Adaption von DUSBVB) läuft dagegen.
>
> 'Mal schauen, wo der Unterschied liegt. Läuft den USB View? Mein Projekt
> ist auf der Grundlage des Sourcecodes von letzterem geschrieben.
>
USBView (die C-Version) läuft korrekt. Leider zeigt diese ja nur die
Stringindices an, nicht die Strings selber. Vielleicht könnte das ja
jemand aufbohren :-)
Ulrich Korndoerfer
Thorsten Albers schrieb:
> Frank Landen <franklan...@gmx.de> schrieb im Beitrag
> <97wg37wcmidy$.lnf81f6oosvv$.d...@40tude.net>...
>> Bei mir läuft USBview - aber deine Umsetzung zeigt mir auch an, dass er
>> keine USB-Geräte findet. System: XP-SP2 und VIA-USB-Chip.
>
> Möglicherweise hängt's einfach nur an den CreateFile() aufrufen:
>
> 1. (2. Parameter) Ich habe immer mit GENERIC_READ und GENERIC_WRITE
> aufgerufen. GENERIC_READ müßte aber eigentlich ausreichen, da die
> Parameter-Übergabe m.W. nicht unter Schreibvorgang fällt. Da GENERIC_WRITE
> sicherlich andere Rechte braucht als GENERIC_READ, könnte es daran
> scheitern.
>
> 2. (4. Parameter) Da ich das ganze unter Window 98 SE geschrieben habe,
> habe ich keine Securit Attributes-Struktur übergeben. Auch daran könnte es
> liegen.
>
> 3. (6. Parameter) Sonst wäre vielleicht auch noch mit den
> 'dwFlagsAndAttributes' herumzuspielen...
Bei mir (DUSVB_Refactored) verwende ich:
Public Type Security_Attributes
nLength As Long
lpSecurityDescriptor As Long
bInheritHandle As Long
End Type
Public Declare Function CreateFile Lib "kernel32" Alias "CreateFileA" _
(ByVal lpFileName As String, _
ByVal dwDesiredAccess As Long, _
ByVal dwShareMode As Long, _
ByRef lpSecurityAttributes As
Security_Attributes, _
ByVal dwCreationDisposition As Long, _
ByVal dwFlagsAndAttributes As Long, _
ByVal hTemplateFile As Long) As Long
Public Const GENERIC_READ As Long = &H80000000
Public Const GENERIC_WRITE As Long = &H40000000
Public Const FILE_SHARE_READ As Long = &H1
Public Const FILE_SHARE_WRITE As Long = &H2
Public Const OPEN_EXISTING As Long = 3
und als Wrapper:
Public Function gUSB_OpenConnection(ByRef Name As String) As Long
Const METHODNAME As String = "gUSB_OpenConnection"
Dim SA As Security_Attributes, Handle As Long
Handle = CreateFile("\\.\" & Name, GENERIC_READ Or GENERIC_WRITE,
FILE_SHARE_READ Or FILE_SHARE_WRITE, SA, OPEN_EXISTING, 0, 0)
gErrorExit (Handle <= 0), "Could not open a connection to " & Name,
METHODNAME
gUSB_OpenConnection = Handle
End Function
Thorsten Albers
> Bei mir (DUSVB_Refactored) verwende ich:
> Handle = CreateFile("\\.\" & Name, GENERIC_READ Or GENERIC_WRITE,
> FILE_SHARE_READ Or FILE_SHARE_WRITE, SA, OPEN_EXISTING, 0, 0)
> gErrorExit (Handle <= 0), "Could not open a connection to " & Name,
> METHODNAME
Demnach hängt es tatsächlich an dem 4. Parameter, d.h. unter Windows NT/XP
>muß< hier eine Struktur übergeben werden, unter Windows 98 >darf keine<
Stuktur übergeben werden. Ändere doch einfach 'mal alle
CreateFile()-Stellen in meinem Modul und teste es dann noch 'mal.
Ich werde das Modul 'mal anpassen und dann in der neuen Form wieder an
derselben Stelle in's Netz stellen.
> USBView (die C-Version) läuft korrekt. Leider zeigt diese ja nur die
> Stringindices an, nicht die Strings selber. Vielleicht könnte das ja
> jemand aufbohren
Welche Version verwendest Du? Die Version "5.1.2600.0 built by: WinDDK"
zeigt bei mir sowohl den jeweiligen Descriptor Index als auch den String
an.
Thorsten Albers
> USBView (die C-Version) läuft korrekt. Leider zeigt diese ja nur die
> Stringindices an, nicht die Strings selber. Vielleicht könnte das ja
> jemand aufbohren :-)
Welchen Fehler meldet denn mein Test-Programm?
a) "The USB information data couldn't be retrieved"
oder
b) "No USB information data available"
Bei a) ist ein Fehler beim Ermitteln der Daten aufgetreten, bei b) konnten
keine USB-Informationen ermittelt werden.
Ich tippe 'mal auf a)... (siehe auch mein anderes Posting!)
Ulrich Korndoerfer
Thorsten Albers schrieb:
> Ulrich Korndoerfer <ulrich_wa...@prosource.de> schrieb im Beitrag
> <43F11A59...@prosource.de>...
>> Bei mir (DUSVB_Refactored) verwende ich:
>> ...
>> Handle = CreateFile("\\.\" & Name, GENERIC_READ Or GENERIC_WRITE,
>> FILE_SHARE_READ Or FILE_SHARE_WRITE, SA, OPEN_EXISTING, 0, 0)
>> gErrorExit (Handle <= 0), "Could not open a connection to " & Name,
>> METHODNAME
>> ...
>
> Demnach hängt es tatsächlich an dem 4. Parameter, d.h. unter Windows NT/XP
>>muß< hier eine Struktur übergeben werden, unter Windows 98 >darf keine<
> Stuktur übergeben werden. Ändere doch einfach 'mal alle
> CreateFile()-Stellen in meinem Modul und teste es dann noch 'mal.
> Ich werde das Modul 'mal anpassen und dann in der neuen Form wieder an
> derselben Stelle in's Netz stellen.
>
>> USBView (die C-Version) läuft korrekt. Leider zeigt diese ja nur die
>> Stringindices an, nicht die Strings selber. Vielleicht könnte das ja
>> jemand aufbohren
>
> Welche Version verwendest Du? Die Version "5.1.2600.0 built by: WinDDK"
> zeigt bei mir sowohl den jeweiligen Descriptor Index als auch den String
> an.
V 5.0.2195.1620. Hab nichts besseres gefunden. Wo hast Du die Deine her?
Ulrich Korndoerfer
Thorsten Albers schrieb:
> Ulrich Korndoerfer <ulrich_wa...@prosource.de> schrieb im Beitrag
> <43F1168...@prosource.de>...
>> USBView (die C-Version) läuft korrekt. Leider zeigt diese ja nur die
>> Stringindices an, nicht die Strings selber. Vielleicht könnte das ja
>> jemand aufbohren :-)
>
> Welchen Fehler meldet denn mein Test-Programm?
> a) "The USB information data couldn't be retrieved"
> oder
> b) "No USB information data available"
> Bei a) ist ein Fehler beim Ermitteln der Daten aufgetreten, bei b) konnten
> keine USB-Informationen ermittelt werden.
> Ich tippe 'mal auf a)... (siehe auch mein anderes Posting!)
Es meldet gar keinen Fehler. Es startet, die Hauptform erscheint, aber
die Treeview links ist leer und die Listbox rechts natürlich auch.
SK
BabelFish.
I wrote similar code, but still can't read USB key serial number.
Can you read serial numbers?
SK
Ulrich Korndoerfer
SK schrieb:
> Sorry for not speaking german - I read your posts with the help of
> BabelFish.
>
> I wrote similar code, but still can't read USB key serial number.
>
> Can you read serial numbers?
>
As I already told you over there in m.p.v.g.d, serials can be read
already using a VB only solution. *But* it is unstable and far from
being able to be used in a production environment. Many people here work
on it to get better. Some more time is needed until a production stable
version is reached. When finished (if ever), I will post it on my home page.
You can get my experimental current version for reading serials from
http://www.proSource.de/Temp/DUSVB_Refactored.zip
It is a modified version of COMMVB.zip from
http://www.intel.com/intelpress/usb/examples/ZipFiles/commVB.htm
Also Thorsten is working on his own implementation by doing it from
scratch, using the Win DDK USB View example (written in C) and
translating it to VB. His first result is available from
http://omnibus.uni-freiburg.de/~albers/snippets/usbinfo10.zip
All read in direct the serial id of an USB device, out of its device
descriptor.
For testing and comparing other methods for retrieving hardware data
(from where the serial may be extractable too) you can use my
http://www.proSource.de/Temp/Test_ReadHardwareData.zip
which since today has the new version 0.2
This program and the above programs are *highly experimental*. May be
they even could *damage your hardware*. So beware, analyze their code
and use them on your own risk.
Ulrich Korndoerfer
Ulrich Korndoerfer schrieb:
>> ...
>> Welchen Fehler meldet denn mein Test-Programm?
>> a) "The USB information data couldn't be retrieved"
>> oder
>> b) "No USB information data available"
>> Bei a) ist ein Fehler beim Ermitteln der Daten aufgetreten, bei b)
>> konnten
>> keine USB-Informationen ermittelt werden.
>> Ich tippe 'mal auf a)... (siehe auch mein anderes Posting!)
>
>
> Es meldet gar keinen Fehler. Es startet, die Hauptform erscheint, aber
> die Treeview links ist leer und die Listbox rechts natürlich auch.
Ups, da muß man ja erst einen Knopf drücken :-)
Und dann kommt Fehler a :-)
Andreas Maurer
<ulrich_wa...@prosource.de> wrote:
Hallo Ullrich,
hast Du mittlerweile eine brauchbare Lösung gefunden?
Falls nicht, poste ich meinen Code - ich habe eine Applikation, die
exakt das macht, was Deine tun soll, und die ebenfalls mit ihrem
MemoryStick verdongelt ist.
Andreas
Bye
Andreas
Thorsten Albers
> V 5.0.2195.1620. Hab nichts besseres gefunden. Wo hast Du die Deine her?
Von dem Link, den Uwe hier in einem früheren Posting angegeben hat:
http://www.redcl0ud.com/files/USBView.cab
Uwe Sieber
Ulrich Korndoerfer wrote:
> Ursache dafür dürfte sein, daß die Hostcontroller unter Zuhilfename
> ihrer symbolischen Namen ("\\.\HCDn") gesucht werden. Das scheint bei
> meiner Konfiguration (USB1.1 auf dem Motherboard und zusätzlich USB2.0
> auf einer Karte) Probleme zu machen.
>
> Abhilfe wäre, die Hostcontroller nicht über ihre symbolische Namen
> sondern anders aufzulisten. Hat da jemand eine Idee?
Das prinzipielle Vorgehen wird in diesem Power-Basic Beispiel
deutlich:
http://www.powerbasic.com/support/forums/Forum4/HTML/005197.html
Da wo tHidGuid verwendet wird, muß man GUID_CLASS_USB_HOST_CONTROLLER
nehmen. In der usbiodef.h ist die so definiert:
#define GUID_CLASS_USB_HOST_CONTROLLER GUID_DEVINTERFACE_USB_HOST_CONTROLLER
/* 3ABF6F2D-71C4-462a-8A92-1E6861E6AF27 */
DEFINE_GUID(GUID_DEVINTERFACE_USB_HOST_CONTROLLER,
0x3abf6f2d, 0x71c4, 0x462a, 0x8a, 0x92, 0x1e, 0x68, 0x61, 0xe6, 0xaf, 0x27);
CreateFile liefert dann die gleichen Handles wie beim Öffnen über
die symbolischen Namen, nur daß man dann alle Hostcontroller findet.
Gruß Uwe
Ulrich Korndoerfer
Andreas Maurer schrieb:
> Hallo Ullrich,
>
> hast Du mittlerweile eine brauchbare Lösung gefunden?
>
> Falls nicht, poste ich meinen Code - ich habe eine Applikation, die
> exakt das macht, was Deine tun soll, und die ebenfalls mit ihrem
> MemoryStick verdongelt ist.
> ...
Wenns Dir nichts ausmacht, gerne - interessiert wäre ich schon (schon
alleine um zu sehen wie man es auch lösen könnte).
Momentan bin ich ja erstmal auf der Suche nach einem Puzzleteilchen
davon - zuverlässig die Serial ID eines USB-Sticks auslesen zu können.
Ulrich Korndoerfer
Thorsten Albers schrieb:
> Ulrich Korndoerfer <ulrich_wa...@prosource.de> schrieb im Beitrag
> <43F1594C...@prosource.de>...
>> V 5.0.2195.1620. Hab nichts besseres gefunden. Wo hast Du die Deine her?
>
> Von dem Link, den Uwe hier in einem früheren Posting angegeben hat:
> http://www.redcl0ud.com/files/USBView.cab
>
Das zeigt bei mir auch nicht den serial *string* an, wenn der serial
*index* im descriptor gesetzt ist. Ich seh dann also nur zB iSerial = 0x03.
Und im Paket war nur die kompilierte Version drin. Wo gibts den die Sourcen?
Ulrich Korndoerfer
Ulrich Korndoerfer schrieb:
> Hallo Andreas,
>
> Andreas Maurer schrieb:
>
>> Hallo Ullrich,
>>
>> hast Du mittlerweile eine brauchbare Lösung gefunden?
>>
>> Falls nicht, poste ich meinen Code - ich habe eine Applikation, die
>> exakt das macht, was Deine tun soll, und die ebenfalls mit ihrem
>> MemoryStick verdongelt ist.
>> ...
>
>
> Wenns Dir nichts ausmacht, gerne - interessiert wäre ich schon (schon
> alleine um zu sehen wie man es auch lösen könnte).
>
> Momentan bin ich ja erstmal auf der Suche nach einem Puzzleteilchen
> davon - zuverlässig die Serial ID eines USB-Sticks auslesen zu können.
>
Ich sehe gerade, Du hast mir das ja auch "nach Hause" gesendet. Ein
Versehen oder willst Du wirklich Deinen Code *hier* veröffentlichen?
Thorsten Albers
Zunächst einmal: Ich habe jetzt eine neue Version des Moduls und des
Testprogrammes unter
http://omnibus.uni-freiburg.de/~albers/snippets/usbinfo10.zip
bereitgestellt.
Darin habe ich berücksichtigt:
a) SECURITIY_ATTRIBUTES bei NT/XP erforderlich
b) Unter bestimmten Bedingungen erfaßt CreateFile("HCD...", ...) nicht alle
Host-Controller (MS KB Q838100)
c) Einige Devices (in bestimmten Umgebungen?) erfordern
IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX statt
IOCTL_USB_GET_NODE_CONNECTION_INFORMATION (MS KB Q838100)
Bin 'mal gespannt, ob das jetzt funktioniert.
Di ZIP-Datei enthält auch die kompilierte TestUSBInfo10.exe sowie 2
Screenshots, wie das bei mir auf 2 verschiedenen Computern mit mehreren
angeschlossenen USB-Geräten rüberkommt.
Was auf jeden Fall noch fehlt: eine Prüfung auf das Vorhandensein der
SETUPAPI.DLL und der CFGMGR32.DLL in einer ausreichenden Version.
> Das zeigt bei mir auch nicht den serial *string* an, wenn der serial
> *index* im descriptor gesetzt ist. Ich seh dann also nur zB iSerial =
0x03.
> Und im Paket war nur die kompilierte Version drin.
Ich seh's gerade:
Windows 98 SE, mit
- on-board USB-Controller mit 2 USB 1.1-Ports und
- PCI-USB-Karte mit 4 USB 2.0-Ports
a) Stick in 2.0-Port der PCI-Karte:
USB View zeigt nur die Indizes an, >nicht< die Strings
b) Stick in 1.1-Port auf Board:
USB View die Indizes >und< die Strings
Das ist merkwürdig, da liegt wohl ein Bug vor.
Bei meinem eigenen Programm wird bei mir alles angezeigt.
> Wo gibts den die Sourcen?
Tja ha, da muß man findig sein... Sie sind oder waren wohl 'mal Bestandteil
des DDK - aber wer hat das schon?
Da das Programm ein kleines Tool von MS ist und USBVIEW.EXE heißt, kann man
mit einiger Wahrscheinlichkeit davon ausgehen, daß eine der
Quellcode-Dateien USBVIEW.H heißt. Googled man danach, finden sich 3
Treffer. Ich bekomme zwar keinen Zugriff auf den ersten (irgendetwas mit
"www-f9.ijs.si/..."), aus dem Google-Cache kann man ihn dann aber noch
holen. Unter einem anderen Treffer (irgendetwas mit "USB-IF :: ...") findet
sich eine Liste der Quellcode-Dateien, die man dann, wie bei USBVIEW.H
ent-Google-cachen kann. Lediglich ein paar unwichtige Dateien sind nicht
verfügbar.
Ulrich Korndoerfer
Thorsten Albers schrieb:
> Ulrich Korndoerfer <ulrich_wa...@prosource.de> schrieb im Beitrag
> <43F20B89...@prosource.de>...
> Zunächst einmal: Ich habe jetzt eine neue Version des Moduls und des
> Testprogrammes unter
> http://omnibus.uni-freiburg.de/~albers/snippets/usbinfo10.zip
> bereitgestellt.
> Darin habe ich berücksichtigt:
> a) SECURITIY_ATTRIBUTES bei NT/XP erforderlich
> b) Unter bestimmten Bedingungen erfaßt CreateFile("HCD...", ...) nicht alle
> Host-Controller (MS KB Q838100)
> c) Einige Devices (in bestimmten Umgebungen?) erfordern
> IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX statt
> IOCTL_USB_GET_NODE_CONNECTION_INFORMATION (MS KB Q838100)
>
> Bin 'mal gespannt, ob das jetzt funktioniert.
>
Auf meinem Desktoprechner (WIN2K Sp4, 2 x USB1.1 (2 und 3 ports) on
board, 1 x USB2.0 (5 ports) auf PCI-Karte) immer noch der gleiche Fehler:
"The USB information data couldn't be retrieved!"
> Di ZIP-Datei enthält auch die kompilierte TestUSBInfo10.exe sowie 2
> Screenshots, wie das bei mir auf 2 verschiedenen Computern mit mehreren
> angeschlossenen USB-Geräten rüberkommt.
>
Sieht wirklich gut aus. Mal sehen, wann ich das auch bei mir sehen kann ;-)
> Was auf jeden Fall noch fehlt: eine Prüfung auf das Vorhandensein der
> SETUPAPI.DLL und der CFGMGR32.DLL in einer ausreichenden Version.
>
Setupapi.dll hat bei mir die Version 5.0.2195.6622.
CFGMGR32.dll hat bei mir die Version 5.0.2134.1.
>> Das zeigt bei mir auch nicht den serial *string* an, wenn der serial
>> *index* im descriptor gesetzt ist. Ich seh dann also nur zB iSerial =
> 0x03.
>> Und im Paket war nur die kompilierte Version drin.
>
> Ich seh's gerade:
>
> Windows 98 SE, mit
> - on-board USB-Controller mit 2 USB 1.1-Ports und
> - PCI-USB-Karte mit 4 USB 2.0-Ports
>
> a) Stick in 2.0-Port der PCI-Karte:
> USB View zeigt nur die Indizes an, >nicht< die Strings
> b) Stick in 1.1-Port auf Board:
> USB View die Indizes >und< die Strings
>
> Das ist merkwürdig, da liegt wohl ein Bug vor.
>
Aha. Bei mir stecken die Sticks bis jetzt auch immer an einem der Ports
der USB2.0 Karte bzw genauer an einem Hub, der seinerseits wieder an der
USB2.0 Karte hängt. Umstecken auf einen der USB1.1 ports bringt bei mir
nichts, da die Sticks dann merkwürdigerweise nicht erkannt werden (zB
erscheinen sie nicht im Explorer als Laufwerk).
Und nun ein Test am Laptop (WIN2K SP4, 1 USB2.0 Host on board mit 2
ports). Setupapi.dll und CFGMGR32.dll haben die gleiche Version wie auf
meinem Desktoprechner. Die TestUSBInfo10.exe einfach rüberkopiert.
Bingo! USBView zeigt auch die Strings an und Dein Programm läuft wie Butter!
Na sowas. Mein Desktoprechner hat ja eine ähnliche Konfiguration bezgl.
USB wie Deiner.
Habe jetzt den Stick mal direkt an einen der USB2.0 ports am Desktop
angesteckt. USBView zeigt weiterhin nur die Indices und nicht die
zugehörigen Strings an.
Und jetzt den Stick direkt an einen der USB1.1 ports. Ebenfalls alles
wie gehabt: das System erkennt das Device nicht, USBView vermeldet: kein
Device angeschlossen (auch nach mehrmaligem Refresh der Anzeige).
Also irgendwas ist an meinem Desktop bezüglich USB faul. Muß da mal
nachforschen.
> Bei meinem eigenen Programm wird bei mir alles angezeigt.
>
>> Wo gibts den die Sourcen?
>
> Tja ha, da muß man findig sein... Sie sind oder waren wohl 'mal Bestandteil
> des DDK - aber wer hat das schon?
> Da das Programm ein kleines Tool von MS ist und USBVIEW.EXE heißt, kann man
> mit einiger Wahrscheinlichkeit davon ausgehen, daß eine der
> Quellcode-Dateien USBVIEW.H heißt. Googled man danach, finden sich 3
> Treffer. Ich bekomme zwar keinen Zugriff auf den ersten (irgendetwas mit
> "www-f9.ijs.si/..."), aus dem Google-Cache kann man ihn dann aber noch
> holen. Unter einem anderen Treffer (irgendetwas mit "USB-IF :: ...") findet
> sich eine Liste der Quellcode-Dateien, die man dann, wie bei USBVIEW.H
> ent-Google-cachen kann. Lediglich ein paar unwichtige Dateien sind nicht
> verfügbar.
>
Na dann werde ich mich mal auf die Suche machen :-)
Peter Götz
ich bin gerade dabei, die Sache mit VB.net zu lösen, habe dort aber bisher
auch noch keine zuverlässige Lösung.
Dein Testprogramm (TestUSBInfo10.exe) habe ich gerade mal heruntergeladen
und hier auf einem Win2k-Rechner getestet.
Der Rechner hat einen USB-CardReader mit 4 Slots.
Beim Test war zusätzlich ein USB-Memorystick gesteckt.
> Welchen Fehler meldet denn mein Test-Programm?
Beim Klick auf den Button "Get USB Node Info":
The USB information data couldn't be retrieved
Beim Klick auf den Button "Get USB Device Info" sehe ich dann folglich im
Fenster "USB Device Info" den Text: "Either there are no USB devices
connected or an USB data error has occured!"
Heute nachmittag werde ich das mal auf div. XP-Rechnern testen.
Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tips u. Beispielprogrammen)
Thorsten Albers
> Also irgendwas ist an meinem Desktop bezüglich USB faul. Muß da mal
> nachforschen.
Üblicherweise sagt man ja, daß, wenn bei USB irgendetwas in dieser Art
schief läuft, ein Energie-Problem besteht. Defekte Elkos auf dem
Motherboard? Bootet der Desktop zufällig nicht so ganz sauber.
Ansonsten wären da ja auch im BIOS-Setup noch einige Einstellungen, die USB
beeinflußen...
Thorsten Albers
<#d$sQPiMG...@TK2MSFTNGP10.phx.gbl>...
> Dein Testprogramm (TestUSBInfo10.exe) habe ich gerade mal heruntergeladen
> und hier auf einem Win2k-Rechner getestet.
Wann? Ich habe gestern nacht um ca. 00:30 Uhr eine neue Version unter der
gleichen URL bereitgestellt, die 3 bekannte Probleme u.a. mit Win2K beheben
soll.
Peter Götz
> > Dein Testprogramm (TestUSBInfo10.exe) habe ich gerade mal
heruntergeladen
> > und hier auf einem Win2k-Rechner getestet.
>
> Wann?
Heute vormittag so gegen 10 Uhr.
> Ich habe gestern nacht um ca. 00:30 Uhr eine neue Version unter der
> gleichen URL bereitgestellt, die 3 bekannte Probleme u.a. mit Win2K
beheben
> soll.
Inzwischen habe ich auch auf 4 verschiedenen XP-Rechnern getestet. Gleiches
Verhalten wie beim Test heute vormittag auf Win2k.
Frank Landen
Am Wed, 15 Feb 2006 02:17:07 +0100 schrieb Ulrich Korndoerfer:
> Thorsten Albers schrieb:
>
>> Zunächst einmal: Ich habe jetzt eine neue Version des Moduls und des
>> Testprogrammes unter
>> http://omnibus.uni-freiburg.de/~albers/snippets/usbinfo10.zip
>> bereitgestellt.
[...]
>> Bin 'mal gespannt, ob das jetzt funktioniert.
>>
>
> Auf meinem Desktoprechner (WIN2K Sp4, 2 x USB1.1 (2 und 3 ports) on
> board, 1 x USB2.0 (5 ports) auf PCI-Karte) immer noch der gleiche Fehler:
>
> "The USB information data couldn't be retrieved!"
Bingo, genau die Fehlermeldung habe ich auch.
>> Di ZIP-Datei enthält auch die kompilierte TestUSBInfo10.exe sowie 2
>> Screenshots, wie das bei mir auf 2 verschiedenen Computern mit mehreren
>> angeschlossenen USB-Geräten rüberkommt.
>>
>
> Sieht wirklich gut aus. Mal sehen, wann ich das auch bei mir sehen kann ;-)
Jip, die Screenies sehen echt schick aus. Im Moment finde ich alles ausser
weisse Kästen schick :((
>> Was auf jeden Fall noch fehlt: eine Prüfung auf das Vorhandensein der
>> SETUPAPI.DLL und der CFGMGR32.DLL in einer ausreichenden Version.
>>
> Setupapi.dll hat bei mir die Version 5.0.2195.6622.
> CFGMGR32.dll hat bei mir die Version 5.0.2134.1.
Ich habs XP SP2+alle Hotfixes, Asus-Board inkl. Via-USB-Chip
Daher habe ich folgende Dateien:
SETUPAPI:DLL 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
CFGMGR32.DLL 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
Also USBview zeigt meinen Memorystick richtig an. Indiz und String stimmt.
Ich habe derweil in Purebasic gebastelt, da es dort einfach schneller geht
zu experimentieren und bin auf folgendes gestossen. Der Code ist im
allgemeinen verständlich.
Der funktioniert:
=================
'guid festlegen
DiskClassGuid.GUID ; als guid definieren
DiskClassGuid\Data1 = $53F56307
DiskClassGuid\Data2 = $B6BF
DiskClassGuid\Data3 = $11D0
DiskClassGuid\Data4[0] = $94
DiskClassGuid\Data4[1] = $F2
DiskClassGuid\Data4[2] = $00
DiskClassGuid\Data4[3] = $A0
DiskClassGuid\Data4[4] = $C9
DiskClassGuid\Data4[5] = $1E
DiskClassGuid\Data4[6] = $FB
DiskClassGuid\Data4[7] = $8B
OpenLibrary(1,"setupapi.dll")
i=0 ; zähler für die enumeration
hDeviceInfoSet = SetupDiGetClassDevs_(@DiskClassGuid,0,0,$2|$10)
While CallFunction(1,"SetupDiEnumDeviceInterfaces",hDeviceInfoSet,0, _
@DiskClassGuid,i,@DeviceInterfaceInfoData)
i+1
[blabla]
Wend
Der folgende funktioniert nicht:
================================
OpenLibrary(0,"hid.dll")
OpenLibrary(1,"setupapi.dll")
HidGuid.GUID
CallFunction(0,"HidD_GetHidGuid",HidGuid)
i=0
hDeviceInfoSet = SetupDiGetClassDevs_(HidGuid,0,0,$2|$10)
While
CallFunction(1,"SetupDiEnumDeviceInterfaces",hDeviceInfoSet,0,Hidguid,i,@DeviceInterfaceInfoData)
i+1
[blabla]
Wend
Irgendwo spielt die hid.dll eine Rolle. Werden etwa nicht alle Geräte als
HID von Windows erkannt? Wenn ich die Geräte direkt nach der DickClass Guid
lese, bekomme ich alle Speichergeräte (Festplatten, Sticks) schön
aufgelistet. Gehe ich über GetHidGuid, dann bekomme ich zwar eine Guid
zurück, aber scheinbar wird diese nicht mehr sauber enumeriert.
D.h. "SetupDiEnumDeviceInterfaces" ist mit DiskClass-Variante<>0 und bei
GetHIDguid=0
Ich habe nun beide Varianten mal mit Consolenausgabe versehen und hier als
exe geuppt: http://www.bullshit2000.de/usb.zip
Bitte schaut mal, was die bei euch machen. Bei mir zeigt USB1 die
Gerätenamen an, aber gibt keine Strings (Manufaktur, Produkt, Serial)
wieder. USB2 zeigt keinerlei Infos an.
Weiter suchend, was die Hid.dll so magisches an sich hat..
Frank
Herfried K. Wagner [MVP]
"Peter Götz" <gssg_...@t-online.de> schrieb:
>> Ich habe gestern nacht um ca. 00:30 Uhr eine neue Version unter der
>> gleichen URL bereitgestellt, die 3 bekannte Probleme u.a. mit Win2K
> beheben
>> soll.
>
> Inzwischen habe ich auch auf 4 verschiedenen XP-Rechnern getestet.
> Gleiches
> Verhalten wie beim Test heute vormittag auf Win2k.
... auch bei mir (Windows XP Professional SP2) dasselbe.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>