開通だよ、おっとぅ

あめりあでふ。
本日は、SPYZドライバがジオング程度になりましたので報告です。
えー。
先日は2ndインタフェースにアクセスすればうーたらこーたらとか妄想して終わったんでしたっけ。
妄想は現実なり。
まず、パイプちゅうことで、この2ndインタフェースアクセスを試みましたところ、
USBD_ParseConfigurationDescriptorEx()
でインタフェース番号を直指定することで2ndへアクセスが出来まして、後はオートでBULK INのパイプがパックリ開通しました(USB Viewで確認)。
さてさて。
ここからが問題ちゅうか、どうやってコマンドを投げれば良いのかとlinuxドライバのコードリーディングをしていると驚愕の事実が。
→コマンドはBULK OUT上で実装するんだと思い込んでいた
戦慄のベンダリクエスト！！
おぉぉおおぉぅ。
そうだったのかー
ベンダリクエスト(コントロール転送)で軽度データの双方向通信を実現し、イメージデータだけバルク転送ちゅうことか？だから、シングルバルク(IN)なのかー。うんうん。納得かもしれない。
だけど。
ベンダリクエストなんてしたことないよ。。。
そもそも、コントロール転送ちゅうたって、ディスクリプタ取得部分なんてちゃんとコード読んだことないし、IOControlの時点では既にローカルに保存されている状態だしで、標準ディスクリプタの実装なんて参考にならないぜーべいべて。
なので、あめりあ、まずコントロール転送用のデフォルトパイプのハンドルを取得してから、WriteFile/ReadFileで強引にコントロール転送パケットを流し込んでみたのさ！
カーネル側でパラメタエラーちゅうのが、DebugViewで表示されてるよぉ。。おっとう。
該当コード(Write/ReadのDispatchメソッド)を読んでみると。。
あれれ？
あれれ？
これ、バルクか割り込み転送用に特化してないか？
UsbBuildInterruptOrBulkTransferRequest()
ここで、まず一発ノックアウト。
さて、どうしたものか、ここのディスパッチをコントロール転送も出来るよう改造するかにゃぁて考えど、まずベンダリクエストちゅうよりコントロール転送のやり方しらねーつうううううの！て自分にツッコミまくりで、とりあえず思い浮かぶキーワードでDDK内部をgrepしまくり。
UsbBuildVendorRequest()
これですか？おっとぅ。
ちゅうか、これじゃなきゃ、もう無理。ドライバのデバッグなんてブルーバック連発で鼻血寸前なのに。
これ、実はマクロでUrbへの流し込みを支援するだけのものなんですが、いやぁ、関数名/マクロ名ちゅうのは大事ですね。おかげ様で辿り着くことが出来たんですから。
ここからはあめりあ速かった。
この通り。

デバイスとイメージの情報を取得するコマンド(0x85/0x86)だけの結果ですが、見事に取得出来ています。
んー。
あとは、イメージのダウンロードをBULK IN経由で取得すればOKじゃないのかな！既にBULK INのパイプをパックリしているから、多分、悩むことなく完了しそうです。
やればなんとかなるものですね。
まだ終わってないけど。