SSブログ
ドライバ開発 ブログトップ
前の10件 | 次の10件

ストレージのロゴ取得について [ドライバ開発]

http://blogs.msdn.com/craigrow/archive/2007/12/14/storage-wdk-blog.aspx

If I've said it once, I've said it a hundred times...I have yet to meet anyone on a Windows device team that is not totally dedicated to helping you get your devices logo'd. Storage is one of the very best...check out their excellent WDK blog.

一度いってたとしたら、100回はいっている・・・
今だデバイスのロゴを取得するのにすべてを捧げられるデバイスチームの人には会ったことが無い。
ストレージについてはWDK Blogという非常によいものがあるので、それを参考にしろ。

SCSIについてはこちら
http://blogs.msdn.com/storwdk/default.aspx
全然更新されてないが、ストレージのロゴを取得するときはこれを参考にしろということだろう。しかし、デバッグの方法まで書いてあるあたりに、苦悩が読み取れる

Vistaは今までの部分を刷新+新しい機能追加だからリソースが足りないんだろうなぁ

デバイスドライバ関係のML見ると、結構初心者もまぎれてるが、そういう質問がいっぱいくるんだろう。勝手に切れてぐぐれとか言い出さないのが海外のいいところだと思う。


WDK - Windows Server 2008 RTM [ドライバ開発]

https://connect.microsoft.com/Downloads/DownloadDetails.aspx?SiteID=148&DownloadID=10700
Microsoft connectにてWDKの最新版が公開

デバッガによるx86プログラム解析入門―コンピュータとプログラムの仕組みを覗く

デバッガによるx86プログラム解析入門―コンピュータとプログラムの仕組みを覗く

  • 作者: うさぴょん
  • 出版社/メーカー: 秀和システム
  • 発売日: 2007/07
  • メディア: 単行本

買ったはいいが、まったく読んでなかった本のうちの一冊。
ユーザーモードアプリケーションのリバースエンジニアリングを通して、それに必要な知識が幅広く簡潔にまとまっている。アセンブラの本が退屈で、実際に動いているものを解析して、自分なりに理解したい人には向いていると思う。
プログラミング言語自体がどんどん高級になり、重くなっていく昨今、わざわざC++やりたいような人は、一度は読んでおくと、はまったときの助けになるかもしれない。
クラッキングされて困るソフトウェアを開発する人は必ず読んでおくべき本。
逆に、高級言語で動いてればそれでいいや、というような人にはまったく向いていない。
自分的には、最近は便利になったなぁというのが感想。


SCSIリクエストの種類 [ドライバ開発]

So many ways to send SCSI requests to a driver
http://blogs.msdn.com/peterwie/archive/2008/01/25/so-many-ways-to-send-scsi-requests-to-a-driver.aspx

SCSI関係のリクエストはいくつかあるが、結局のところ以下の2つに対応しとけってことらしい

・カーネルモード内ではIRP_MJ_SCSIが来るかもしれない。
・ユーザーモードからはIOCTL_SCSI_PASS_THROUGH(_DIRECT)がくるだろう

ユーザーモードでの開発にしても、中途半端にSCSIコマンドをサポートしてるように見えるので、初心者ほどはまりやすい。Inquiryなどのコマンドが中途半端にIOCTLコマンドとしてサポートされてるため、SCSIのコマンドサポートするときは、IOCTL_SCSI_PASS_THROUGHだけサポートすればよいということが、リファレンスの羅列ばかりのドキュメントからは一向に伝わってこないからだ。
WDMの開発に関係した書籍も、ことストレージに特化したこの手の命令はまったく無視している。(当然だが)
となると英語のMLを常日頃目を通しておくのがよいのだろうなぁ。


ddkbuild [ドライバ開発]

前にいろいろVisualCの設定を試してみたが、そんなことをしなくていいっぽい

Windows デバイス ドライバのビルド環境http://www.microsoft.com/japan/whdc/devtools/tools/buildenv.mspx

ddkbuildというバッチファイルを使うことで簡単にドライバのビルドができる。
というか、VisualStudioのパスにDDKのパスを指定する以前の方法だと
PlatformSDKを優先的に使用したいプロジェクト(ATLなど)で
コンパイルがうまく通らないという問題が発生した。
DDKを使うときだけパスを指定してくれるこっちのほうがお手軽でよい。

しかし、完全に最初からこれをつかってビルドしようとすると
いくつかの落とし穴が存在する

dirsやsources,makefileを用意する必要がある
コンパイルオプションなどはsourcesで設定する

これがちゃんとできてないと、当然のことながらコンパイルはうまく通らない。
DDKのサンプルであれば、最初からsourcesなどは用意されているはずなので
問題ないが、完全に1からコンパイルしようとすると割りと面倒。

また、VisualStudioで関数の定義などを調べるのに使うブラウザファイルも
sourcesに

BROWSER_INFO=1
BROWSERFILE=browserfile.bsc

などと書く必要がある

ファイルシステムをコンパイルする場合(NTIFS.Hを使いたい場合)は

DRIVERTYPE=FS

を追加する必要がある

あと、この方法だと、デバッグビルドとリリースビルドの切り替えが
スマートではないという問題もある。
(ターゲット先やコンパイル時のマクロを指定できない)

ちゃんと調べればできそうな気もするが、また今度。


Advanced Windows Debugging [ドライバ開発]

Advanced Windows Debugging

デバッグ方法の集大成みたいな本みたい
開発者は読むべき

といっておいて自分はまだ読んでない
今の仕事はデバッグが厄介なので、会社で買ってもらおう
でよかったら自分でも買う

Advanced Windows Debugging (Addison-Wesley Microsoft Technology)

Advanced Windows Debugging (Addison-Wesley Microsoft Technology)

  • 作者: Mario Hewardt, Daniel Pravat
  • 出版社/メーカー: Addison-Wesley Pub (Sd)
  • 発売日: 2007/10/26
  • メディア: ペーパーバック

続きを読む


FileBothDirectoryInformation [ドライバ開発]

ファイルシステムの開発で今まで厄介だったのがショートファイル名の存在。
MSDOS形式とか8.3形式とか呼び方が統一されていない上に、ファイルシステムそのものが対応してないシステムだって存在する。

今時のDOSはNT上で動かすならわざわざ8.3にする必要はまったく無いので、機能を切りたかったのだが、呼び方がありすぎるのと、これといったドキュメントが無くあきらめてたが、ふとソースコードを見ていたら発見した。

FileBothDirectoryInformationにあるショートネームの値を0にして返せば、ショートネームを上位の何かが知るすべは無くなるので強制ロングネームになるっぽい。

ファイルシステムにショートネームが無い場合、OSと直接処理をするドライバが、内部でショートネームを作ってサポートしないといけなかったりする。エクスプローラーの場合、必ずディレクトリを開いて、ファイルリストを取得から処理をするので、そのときにショートネームを作ってしまえばよいのだが、DOSの場合、直打ち指定があって、そのときにディレクトリのリストが無かったら取得してショートネームを作らないといけない。きれいなソースコードだったら2,3行で済むかもしれないが、今のソースは激しく汚いので、サポートしないほうが100倍楽だったりする。

で、こういうOSべったりなファンクションについてはDDK見るしかなかったりして、大した資料が無い。OSRのMLには参加しないとだめっぽいが、当然全部英語。

最近ぐぐってて思うのは、中国人とかロシア人が積極的にこういうところの開発もやってるが、日本人でやってるって人がまったくいないこと。オワタな気分にならざるを得ない。

そりゃWindows NT ファイルシステム詳説も再販されねーよなー
ちなみに英語版ならOSRから買えるらしい

相変わらず売り切れの日本語版

Windows NT ファイルシステム詳説―A Developer’s Guide

Windows NT ファイルシステム詳説―A Developer’s Guide

  • 作者: ラジーブ ナガール
  • 出版社/メーカー: オライリー・ジャパン
  • 発売日: 1999/01
  • メディア: 単行本(ソフトカバー)

英語版
http://www.osr.com/fsinternals.shtml

ニッチな開発の先の真っ暗さ加減を認識するときと洋ゲーのリリースがされなかったり、遅かったりすると、英語をまともに勉強しておくべきだったと後悔する今日この頃。


アセンブラによる無限ループ、再起動の回避 [ドライバ開発]

VMWareなど、仮想マシンを使っていれば特に問題ないのだが、今の開発では、仮想マシンが使えずリモートデバッグで開発している。
 ブート時に読み込まれるドライバのため、不具合を修正するつもりで、ちょっとした記述ミス(変数の初期化忘れなど)によって、マシンが無限再起動や無限ループしてしまうことがたまにある。

普通のドライバであれば、大体以下のパターンで回避できる

・リモートデバッグしているドライバのイメージがちゃんとあって、変数が見れる場合には、変数に適宜入れて回避できる。(特定の無限ループは回避できるが、当然コードの修正はできない)
・手前に手軽にジャンプできる条件文が無く、絶対にあるルーチンに入ってしまうために、回避できない場合もある。通常のデバイスドライバであれば、そのデバイスをはずしてOSを起動し、正常なドライバに差し替えてから再度デバイスを有効にする。
・起動時にF8を連打して、セーフモードで起動し、そのドライバがロードされないようにする(が、これはカーネルモードサービスに対してはあまり有効ではない)

ほとんどの場合は以上の3パターン、特に2つめの場合で済む。しかし、起動時に読み込まれるドライバの場合にはそうはいかない。セーフモードですら呼ばれるほどの重要性があるドライバの開発の場合、セーフモードにしてもやはり呼びだされてしまう。そこで、カーネルモードサービスの開発では、ダミーで何もしないで抜けられるようにしておく。

DriverEntry( ... )
{
 int status = STATUS_SUCCESS;
 __asm int 3;//デバッグモードだったら一時停止するコードを書いておく
 if( status ) {
  return STATUS_UNSUCCESSFUL;
 }

..

return status;
}

起動時にいちいちデバッガが停止するが、こうしておくことで、status変数をデバッガで変えることによって、ドライバがロードされず、無限再起動から抜けられることも多い。

ところが、デバッグ中にうかつにもコンパイルしてしまうと、リモートのイメージとローカルのそれが一致しないため、変数を書き換えることができなくなってしまう。そんなときに、マシン語を使う。メモリ上のコードを書き換えて、エラーが発生したらリターンするルーチンまでジャンプさせることで対応する。ret,jmp、push,cmp程度の命令ですむので、アセンブラに詳しくなくてもどうにかなる。最悪nopで最後のリターンまで埋め尽くせばよい。

上記のようなソースで ... の箇所に例外発生箇所がある場合には、statusと思われる変数に0以外の値を入れて、最後のreturn statusのところにジャンプするようにすれば、間の処理をすべて飛ばせる。

そもそもOSのイメージを作っておくのは当然といわれればそれまでだが、2003対応のバックアップソフトが高すぎるのでこんなことをやらないといかんかった。


__security_check_cookie が 解決できない [ドライバ開発]

LNK2001:unresolved external symbol __security_check_cookie or __security_cookie

W2K3SP1DDKとDriverStudioを使ってコンパイルするとこんなのがでた。
bufferoverflowK.libをリンクすることで解決できる。

bufferoverflow.libやbufferoverflowU.libというのもあるようだが、ユーザーモード用なのでドライバには関係ない。
どうも新しいPlatformSDKなどで、セキュリティ向上のために入れてあるルーチンが解決できてないらしいが、よくわからん。


Visual Studio を使ってドライバをコンパイルする方法(暫定版) [ドライバ開発]

http://alter.org.ua/en/docs/nt_kernel/vc8_x64_proj/
Building NT kernel mode drivers in MS Visual Studio 8.0 (VS 2005) for x64 (AMD64) platform

DDKのサンプルは全部Makeファイルになっているので開発が非常にだるい。と思っていたところ、こんなものを発見したので暫定メモ(動作確認はまだ)。

手元のVisualStudio2003と2005を比較したところ、サブシステムのところに、いくつか項目が増えていた。2003ではConsoleとWindowsしかなかったが、2005ではNative他いくつかの項目が追加されている模様。新しいWDKによるものかは不明。

詳細は省くが、

・空のDLLプロジェクトを作る

C/C++
コード生成
・バッファのセキュリティチェック:いいえ (/GS-)
詳細
・呼び出し規約:__stdcall (/Gz)

リンカ
全般
・インクリメンタルリンクを有効にする:インクリメンタル リンクを行わない (/INCREMENTAL:NO)
・インポートライブラリの無視:はい
入力
・すべての規定のライブラリの無視:はい (/NODEFAULTLIB)
・追加の依存ファイルにntoskrnl.libとHal.libを追加
システム
・サブシステムを"ネイティブ (/SUBSYSTEM:NATIVE)"
・ドライバをドライバ (/DRIVER)
詳細
・エントリポイント:”DriverEntry”
・コマンドラインに"/safeseh:no" を追加
でいけるっぽいが、まだ動作未確認。

ドライバのインクルードファイルやライブラリはPlatformSDKとはかなり相性が悪いので、

2003でもコマンドラインオプションから追加すれば、nativeオプションが指定できるが、ドライバオプションが無いので、ベースアドレスとかいじらないとだめっぽい。


C++によるドライバの開発 [ドライバ開発]

http://www.microsoft.com/japan/whdc/driver/wdf/WDF_FAQ.mspx
FAQ: ドライバ開発者からの Windows Driver Foundation に関する質問

Q.KMDF は、C++ でのドライバの作成をサポートしますか?
A.KMDF は、C でのカーネル モード ドライバの開発をサポートしますが、現在 C++ はサポートしていません。現在使用可能な C++ コンパイラからの出力は、すべての Windows プラットフォームおよびバージョンのカーネルモードで機能することが保証されていません。Microsoft は、C++ をカーネルでより便利に使えるようにするための方法を調査しています。

カーネル モードでの C++ の使用の詳細については、「C++ for Kernel Mode Drivers: Pros and Cons」を参照してください。

http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx
C++ for Kernel Mode Drivers: Pros and Cons

Cで書かれた汚すぎるコードをきれいにするには、C++としてコンパイルするのが良いと思っているが、ドライバは基本的にC++をサポートしていないらしい・・・

クラスは使えなくても、CPPでコンパイルされるだけで、型チェックが厳密になるのでそれだけでもありがたかったりするので、ためしにやってみた。
拡張子をCからCPPに変えて、extern "C"宣言追加などをすれば、一応はコンパイルできるようなのだが・・・もとのソースが汚すぎてエラーが山盛り、コンパイルが通ってもリンカが通るかわからないし、先は長そうだ・・・


前の10件 | 次の10件 ドライバ開発 ブログトップ

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。