ByteScope

HID Report Descriptor Inspector

HID機器をつなぐだけで、レポートディスクリプタの中身とライブの入力レポートがそのまま見えます。

ブラウザ内でローカルに HID デバイスを読み取ります — アップロードは一切行われません。

デバイス未接続

ブラウザの対応状況を確認中…

ブラウザ対応状況

WebHID は現在、Chromium 系のデスクトップブラウザでサポートされています。WebHID の対応状況について詳しくはこちら

機能ChromeEdgeFirefoxSafari
navigator.hid デバイスピッカーChromium 系のデスクトップブラウザのみ対応。対応対応非対応非対応
リアルタイム Input レポートWebHID 経由で Input レポートをリアルタイム受信します。対応対応非対応非対応
Android でのデバイス接続Android では実機検証をしていません。Firefox はどのプラットフォームでも WebHID を実装しておらず、Safari は Android には存在しません。未検証未検証非対応該当なし
ディスクリプタ貼り付けデコード純粋な計算処理 — デバイス不要で、すべてのブラウザで動作します。対応対応対応対応
キーボードまたはマウスを開くWindows は最上位のキーボードおよびマウス Collection を WebHID から完全にブロックします。macOS や Linux では通常許可されます。一部対応一部対応非対応非対応

検出されたブラウザ機能

  • navigator.hid
  • Secure Context (HTTPS)

このツールについて

本ツールはWebHID APIでUSB HID機器に接続します。Connectを押してブラウザの選択ダイアログからキーボード、ゲームパッド、バーコードスキャナ、自作ファームウェアのボードを選ぶと、機器のCollectionとレポートを一覧し、レポートディスクリプタを昔ながらのデスクトップツールと同じインデント形式にデコードして表示します。Usage Page、Usage、Collection、Logical Minimum/Maximum、Report SizeReport Count、Input/Output/Featureのフラグが、アイテム単位でそのまま読めます。処理はすべてブラウザ内で完結し、何もアップロードされません。しかも本バージョンは完全に読み取り専用で、機器へは1バイトも送りません。

ディスクリプタをフィールド単位まで分解する

レポートディスクリプタとは、HID機器がホストに「これからこういうデータを送ります」と宣言するために渡すバイト列です。キーボードがドライバなしで動くのはこの仕組みのおかげで、自作デバイスが動かないときに最初に確認すべき場所でもあります。生のリスティングの下には、Input・Output・Featureの全レポートを展開した表が並びます。レポートID、バイト単位のサイズ、そして各フィールドのビットオフセット、ビット幅、Usage名(Generic Desktop / XKeyboard LeftControlButton 3)、論理レンジ、フラグ。HID Usage Tablesとメモ帳を突き合わせて手作業で組み立てていたあの対応表が、最初からできあがっています。

ビットが変わる瞬間をライブで見る

機器を開くと、入力レポートが届いたそばから流れてきます。片側に生のHEXバイト、その隣にフィールドごとのデコード済みの値。キーを押す、スティックを倒す、バーコードを読ませる——どのビットが変わったかがその場で分かるので、1ビットずれたオフセットや、ディスクリプタの宣言と実際のパッキングが食い違っているフィールドは、たいていこれだけで見つかります。なおWebHIDはChromium系専用のAPIです(デスクトップのChrome、Edge、Opera。Android版Chromeも動くはずですが、こちらでは未検証です。FirefoxとSafariは実装していません)。また、ブラウザが開く前にOSが機器を握ってしまう場合があります——どの機器がなぜ開けないのかは、下のFAQで説明します。

よくある質問

キーボードやマウスが選択ダイアログに出てこないのはなぜですか?

WindowsではChromiumがキーボードとマウスを一律でブロックします。生のキーボードレポートを読めるページは、他のアプリ宛のキー入力を記録できてしまうためで、ダイアログにそもそも表示されません。macOSではたいてい開けます。これとは別に、WebHIDはどのOSでも特定の保護されたUsage Page(たとえばFIDOセキュリティキー)をブロックしますし、ドライバに排他的に握られている機器はブラウザからは一切開けません。

そもそもレポートディスクリプタとは何ですか?

HID機器が列挙時にホストへ提示するコンパクトなバイト列で、送受信するすべてのレポートの構造を宣言します。各フィールドがどのUsage PageとUsageに属するか、何ビットを占めるか、論理レンジはいくつか、Input・Output・Featureのどれか。ホストはこれを一度パースすれば以降のレポートをすべて解釈できます。HID機器に専用ドライバが要らないのはこのためで、デバッグのときに信頼できる唯一の情報源もこのディスクリプタです。

機器のデータがどこかにアップロードされますか?

いいえ。WebHIDはブラウザと機器の間で直接やり取りします。ディスクリプタも、レポートの表も、眺めている入力レポートも、すべて手元のマシンに留まります。サイト側の解析はツールを使ったという事実だけを記録し、機器のデータには一切触れません。

機器への書き込み——Output/Featureレポートの送信はできますか?

できません。これは意図的な設計です。本バージョンはsendReport()sendFeatureReport()も一切呼びません。ディスクリプタを読み、入力レポートを聞くだけなので、リバースエンジニアリング中のハードウェアに向けても安全です。Featureレポートの書き込みは後のバージョンで対応予定です。

デコード結果が自分のファームウェアのコードと合いません。なぜですか?

本ツールは機器が送ってきたバイトをそのままデコードするので、食い違うときはたいてい、ディスクリプタが自分の思っている内容と違います。定番の原因は3つ。機器がレポートIDを使う場合、ワイヤ上の先頭バイトはIDなので全オフセットが8ビットずれる。パディングアイテム(Usageを持たないReport Size×Report Count)が、コード側では暗黙に読み飛ばしているビットを占めている。フィールドのバイト順はディスクリプタのビットレイアウトに従うのであって、構造体の定義には従わない。インデント表示を自分の書いたディスクリプタと突き合わせれば、食い違いはほぼ必ずその中にあります。