アレなカタチで遠回しに。
例えばユニークであるはずのデータがなぜか
製造元によって整形されて一意じゃなくなってしまったとしたら。
分かる人にはピンとくるネタ。
デバイスの一意性を問う必要がある条件でのお話。
以下は一般的なUSBメモリを例にするもので、例示するデバイスに
問題あるとは言っていない。
あるかも知れないが、分からない。単なる例に過ぎない。
この点だけは強調したい。
単に手元にあったUSBメモリを使っているだけの事。
また、自分の都合でLinuxでのコマンド表示を使うが、
実際には事務用OSでの出来事から、腹立たしさをブチまけただけ。
という点も断っておく。
lsusbコマンドで接続しているUSBデバイスの情報を見る。
こんな感じで表示される。
moro@E6510:/proc$ lsusb
Bus 002 Device 004: ID 0a5c:5800 Broadcom Corp. BCM5880 Secure Applications Processor
Bus 002 Device 003: ID 413c:8187 Dell Computer Corp. DW375 Bluetooth Module
Bus 002 Device 005: ID 0930:6544 Toshiba Corp. TransMemory-Mini / Kingston DataTraveler 2.0 Stick (2GB)
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 05ca:1814 Ricoh Co., Ltd HD Webcam
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
ここで次のデバイスに注目する。
Bus 002 Device 005: ID 0930:6544 Toshiba Corp. TransMemory-Mini / Kingston DataTraveler 2.0 Stick (2GB)
実際は32GByteなんだけどな.... なUSB2.0 32Gのフラッシュメモリ デバイス情報を
更に詳細に表示してみる。
moro@E6510:/proc$ sudo lsusb -d 0930:6544 -v
[sudo] moro のパスワード:
Bus 002 Device 005: ID 0930:6544 Toshiba Corp. TransMemory-Mini / Kingston DataTraveler 2.0 Stick (2GB)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0930 Toshiba Corp.
idProduct 0x6544 TransMemory-Mini / Kingston DataTraveler 2.0 Stick (2GB)
bcdDevice 1.00
iManufacturer 1 TOSHIBA
iProduct 2 TransMemory
iSerial 3 7427EA2C39F2CF8090088E30
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 200mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 255
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 255
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
このズラズラと出力される情報から、
idVendor 0x0930 Toshiba Corp.
0x0930 東芝製のデバイスであることが分かる。
idProduct 0x6544 TransMemory-Mini / Kingston DataTraveler 2.0 Stick (2GB)
0x6544 このプロダクトを示す情報、更にその下の
iManufacturer 1 TOSHIBA
iProduct 2 TransMemory
どうやらTransMemoryというプロダクト名らしいことが分かる。
iSerial 3 7427EA2C39F2CF8090088E30
7427EA2C39F2CF8090088E30 から、このプロダクトのシリアル番号を
知ることができる。
このiSerialはHex 16桁のデータであるはず。
以下を見ると付加されている場合は１つ１つのデバイス毎にユニークであるはずなのである。
usb.org辺りのドキュメンテーション
CQ出版社 クラス・ドライバとその基本動作 クラス・ドライバとその基本動作 - CQ出版
上記のデバイスも24桁あったりするようだが、24桁フルに使われていて
上位桁をゼロ埋めしているわけではないので、今回のネタと少し違うのだが。
この例 24桁の上位8桁がゼロ埋めされていて16桁だけに有効データと
思えるデータが設定されているケースを考えてほしい。
つまり、
00000000xxxxxxxxxxxxxxxx
こういうデータがiSerialに設定されていたとする。
仮に以下の条件だったりすると、、
・もしも１６桁に合わせるために下位8桁を落としてトリミングすると仮定
・このシリアル番号がデバイス一つ一つに対してシーケンシャルに加算された１６進または１０進の数値だとする
この条件で下位の8桁をトリミングで落として強引に16桁にしたらどうなるよ？ということ。
単純思考で仮定すると、もしかしたらロット単位での識別は可能かも知れない。
しかしデバイスの固有情報識別には使えないわな。
で、このシリアル番号ってそもそも何よというソモソモ論にいきつくわけです。
これに対して「一意性を保持して保証するものではない」とか
製造元から言われちゃったら、あーそーですか♪ と開き直るしかないのだけどね。
職場で出来事を報告したついでに言ってしまったよ。
「ファームのソースよこせ、俺が直す」と。
周りに笑われてしまったが、「本当に直しそう」と言われたが、
こういうモノ作りをするベンダに腹が立ったり、周りの反応が少し嬉しかったりもした
複雑な出来事だったとさ。
そういうお話。
0 件のコメント:
コメントを投稿