もう一点補足。

> > ウイルス対策ソフトのリアルタイム検索機能で使っているプログラムがそれに
> その手のプログラムは一般にフィルタドライバだったと思います。
とも一概に言い切れないカナ、と思いました。ウィルスソフトも現在となっては
あまりに多くの種類が公開されてるので。

一応、Microsoft OnCareで確認する限りは以下のものがウィルス検知部分であるかと
思います。
・サービス名: MpFilter
・説明: Microsoft On-Access Malware Protection Mini-Filter Driver
・ドライバファイル: system32\DRIVERS\MpFilter.sys
・グループ: FSFilter Anti-Virus

なので、恐らくOneCareは(名前が示すように)フィルタドライバでの分類に属される
のではないかと思われます。

orz、だめぽ。

> OnCare
OneCareです。

私のせいで段々スレッドが汚れてゆく・・・。

解釈が間違っていたので、訂正します。スレッド汚しすぎ（；；

> POSIXサブシステムの場合、ファイルオープン関数→ZwCreateFile()
ファイルオープン関数がopen()として、ググった限りでは以下のようです。

> POSIXサブシステムの場合、open()→NtCreateFile()
ZwCreateFile()については同様に≒の関係で大丈夫だとは思いますが・・・。
(POSIX関連は文献読んだ程度なのでイマイチだめっぽい)

madshiを使う方法は試してみてもいいと思います。

>Win32サブシステムの場合、CreateFile()→NtCreateFile()≒ZwCreateFile()
これはあたってます。
しかし、「ZwCreateFile()」は、正攻法ではカーネルモードでないと動作できない
とおもいます。

POSIXなら可能だと思いますが、Windows環境では無理そうです。
わざわざ「ZwCreateFile()」を使わなくても、ファイル名の代わりにデバイス名を
付けて「CreateFile()」を起動すればカーネルモードで「NtCreateFile() 」が動きま
す。
「ZwCreateFile()」はカーネルモードで「CreateFile()」が使えないので、
代わりに使う関数だと解釈しています。

補足です
>POSIXなら可能だと思いますが、Windows環境では無理そうです。
実際に使った経験はないですが、サイトを調べる限りでは可能みたいですね。

> POSIXなら可能だと思いますが、Windows環境では無理そうです。
> わざわざ「ZwCreateFile()」を使わなくても、ファイル名の代わりにデバイス名を
> 付けて「CreateFile()」を起動すればカーネルモードで「NtCreateFile() 」が動きま
> す。
デバイス名が使用するデバイスに一致していて、かつ、デバイスドライバー
（今回の場合は「USBSTOR.SYS」)が対応していなければならないと思います。
おそらくフックの場合も一緒だと思いますが...........
デバイスが特定されません。

まず最初に、長文失礼します。

要件から幾分か飛んでいますが、無駄な書き込みではないと思いたい
ところです。

う～ん、ITOさんが指摘する部分と私の危惧する部分が異なっているのカナ
と思いました。
(国語力は自他共に認めるほど危険粋なのでお手数をおかけしますが
辛抱強くお願いします)

> しかし、「ZwCreateFile()」は、正攻法ではカーネルモードでないと
> 動作できないとおもいます。

&

> >POSIXなら可能だと思いますが、Windows環境では無理そうです。
> 実際に使った経験はないですが、サイトを調べる限りでは可能みたいですね。
面白そうな文献ですね。差支えがなければググるキーワード程度でも
構いませんので案内していただきたく思います。

私が見てきた限りでは、SYSENTER_EIP_MSRの書き換えカナと思う程度です。
(確か、CodeProjectにこの手の文献が挙がっていたと思います)

もう一点、SSTDに関する部分もあるらしいのですが、実際のコードを見ては
いないので分かりかねる部分です。

私が想定しているコードを以下に示します。

---- インジェクトを行うための実行ファイルのある関数 ----
BOOL InjectDll()
{
　return InjectLibrary(ALL_SESSIONS | SYSTEM_PROCESSES, HOGE_INJECT.DLL);
}

---- インジェクトを行うDLL内の、プロセスアタッチ部 ----

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD dwReason, ...略...)
{
　switch (dwReason)
　{
　　case DLL_PROCESS_ATTACH:
　　{
　　　InitializeMadCHook();
　　　CollectHooks();
　　　HookAPI(kernel32.dll, CreateFileA, MyCreateFileA, (PVOID*)
&m_lpfnCreateFileA);
　　}
　　break;

　　case DLL_PROCESS_DETACH:
　　{
　　　FinalizeMadCHook();
　　}
　　break;
　}
　return TRUE;
}

---- インジェクトを行うDLL内の、CreateFile()の代わりに呼び出される関数 ----

HANDLE MyCreateFileA(LPCTSTR lpFileName, ...略...)
{
　// デバイスの判断、単にWin32_LogicalDiskのMediaTypeで
　// 判断するだけで運用上問題ないのカモしれないし、厳密に
　// デバイス名などのデバイス固有の判断が必要カモしれない
　bMiniSD_Drive = ...(何かしらのコード)...

　// 書き込みを要求しているかどうかの判断。
　bDesireWrite = (dwDesireAccess & GENERIC_WRITE) ? TRUE : FALSE;

　// 関数のCALLERが書込み保護を必要とするかしないかを判断
　bAllowProcess = ...(何かしらのコード)...

　if (bMiniSD_Drive && bDesireWrite & !bAllowProcess)
　{
　　::SetLastError(ERROR_ACCESS_DENIED);
　　return INVALID_HANDLE_FALUE;
　}
　else
　{
　　// 処理をWin32::CreateFileA()に譲位
　　return m_lpfnCreateFileA(lpFileName, ...(略)... );
　}
}

// CreateFileW()についても同様。

> デバイス名が使用するデバイスに一致していて、かつ、デバイスドライバー
> （今回の場合は「USBSTOR.SYS」)が対応していなければならないと思います。
なので、USBSTOR.SYSのようなデバイスドライバ周りの話は無視できるのでは、と
思っています。
(デバドラが出てくると他の方が指摘されているようなブルーバック云々という
問題も発生しかねないので、その代用手段としてmadshiを出させていただきました)

デバイスの特定に関する是非に関しては、アプリケーションを運用する状況に
依存するかと思っています。というのも、社内運用でセキュリティのために
今回のminiSDだけしかリムーバブルメディアをPCに実装しない、ということで
あれば上記のようなWin32_LogicalDiskだけの判断でも十分に事足りるかと
思います。

私が危惧する部分は些細な事だと思っていますが、端的に言えば、状況によって
MyCreateFile()が呼ばれる事無くファイルがオープンできる場合がある、という
ことを指しています。
その状況というのが、Win32サブシステム以外のことであると(文献を読む限りでは)
解釈しています。

ですから、この点に関しても運用云々次第では無視できる項であるとも思っています。
(むしろ、デバイス判定云々よりこのパターンがレアであると思っています)

# 読み返すと私の書いた「直接ZwCreateFile()がコールされた」が全ての失敗
# だったカナと思うところです。単純に、「フックすることに呼ばれる部分が
# 「とある状況」では呼ばれない」と書いたほうがスッキリしたのカモしれません。

何度もすみません、やはり日本語が悪かったです。

> // 処理をWin32::CreateFileA()に譲位
「譲位」ではなくて「委譲」ですね・・・。

> 面白そうな文献ですね。差支えがなければググるキーワード程度でも
> 構いませんので案内していただきたく思います。
POSIXでググると可能だと出てきますね。
WINDOWS環境は、MSDNで調べました。

>私が見てきた限りでは、SYSENTER_EIP_MSRの書き換えカナと思う程度です。
これでフックは出来そうですね。確信はないですが。
問題は、「SYSENTER_EIP_MSR」はCPUのレジスター値ですね。

> もう一点、SSTDに関する部分もあるらしいのですが、実際のコードを見ては
> いないので分かりかねる部分です。
そうですね、これもCPUのレジスターに関わることかも知れませんね。

> 私が想定しているコードを以下に示します。
> なので、USBSTOR.SYSのようなデバイスドライバ周りの話は無視できるのでは、と
> 思っています。
僕も無視できると思います。
フックのところは、madshiに任せることにして、重要なところは、
>bMiniSD_Drive = ...(何かしらのコード)...
おそらくここにデバイス名を含んだ文字列が入るのだと思います。
>　// デバイス名などのデバイス固有の判断が必要カモしれない
必要です。
判定でNGの場合は早急に制御を返さなければならない。
CreateFileは、ディスク関連だけでなく殆どのデバイスに関わる関数です。
CreateFileのフックは慎重に行わないといけません。
ウインドウのシステムがフックをブロックしている可能性があるかも知れません。

> 私が危惧する部分は些細な事だと思っていますが、端的に言えば、状況によって
> MyCreateFile()が呼ばれる事無くファイルがオープンできる場合がある、という
> ことを指しています。
それは、madshiがどこまでフック出来るかに関わってきます。

># 読み返すと私の書いた「直接ZwCreateFile()がコールされた」が全ての失敗
># だったカナと思うところです。

Windows環境の場合
　ZwCreateFile() = カーネルモード
　CreateFile() = ユーザーモード
です。

ちょっと日本語がへんなところがあるかも知れません。
すみませんが、ご承知下さい。

なんか知らん間にながーくなっとる・・・とりあえずまとめてみる

・その対象機器はセクタ番号でデータを読み書きする
　（FAT ファイルシステムの構成などは無視する）
・そのデータを読み書きしたいのでセクタ番号で入出力がしたい
・セクタ番号で入出力する関係で他プロセスに邪魔されたくない
ということでおｋ？

皆アプローチが難しい方向に逝ってるような気がする
（最初にフィルタドライバに話を持ってった俺が悪い？）

その microSD カードを他の目的に使わないのであれば、俺ならこうする
・カード全領域を埋め尽くす巨大ファイルを作る
（＝ファイル先頭からのオフセット＝セクタ番号と読み替えることができる）
・自作プログラムはそのファイルをロックして使う
（ファイルのロック＝カード全体のロックとみなせる）
・セクタ直接入出力を単にファイルの seek/read/write で代用できる
・巨大ファイルが削除されたりファイルサイズが変わったりしたら、
　自作プログラムはエラーを発生させる

これで小難しいテクニックを使わずとも十分代用できそうな気がするがどうだろう

玲音 (st.lain)さま、ITOさま、tetrapodさま
見知らぬ自分のために休日まで潰してアドバイスしてくれて
本当にありがとうございます。（涙以外に言葉は出ません）

CreateFileを使ってますけど、その裏にいろんなことができますね。
勉強になりました。
これもひとつの案になりますね。

ただ、SDカードにデータを書き込む人と
SDカード内のデータを実際利用する人は違います。
デバイス名を見ない限り、空SDカードと認識される可能性があります。
それをデジタルカメラ、携帯電話などにさして使ってしまうと・・・

tetrapodさま、まとめてくれてありがとうございます。
分かりやすい方法ですね。
これもひとつの案として提案します。

皆様、どうもありがとうございました。

> デバイス名を見ない限り、空SDカードと認識される可能性があります。
> それをデジタルカメラ、携帯電話などにさして使ってしまうと・・・

えと。
「専用リーダーで読み取りアクセスをしている最中のみロックする」という前提でずーっ
と話してたと思うんですが、リーダーから外しても読み取り専用にしておきたいんです
か？　専用ライター以外では書けないようにしたいとか？

…無理だと思います。

最初から説明が足りなくて大変申し訳ございません。

最初のレスで
>SDカードのライトプロテクト切り替えでロックかけるような機能を
>microSDカードで実現できるAPIなどはありますでしょうか？
この質問がとってもあいまいなことになってしまいました。

>また、WindowsからアクセスできるSDカードの論理アドレス領域以外にも
>物理アドレスでアクセスできる領域も存在するのでしょうか？
>存在するとしたらどうやってアクセスできるのでしょうか？
>その領域にロックに関する情報もあるのでしょうか？
確かに自分でも分かりにくい言葉・・・

意味の分からない日本語で申し訳ございませんでした。
これから日本語勉強をしっかりしないと・・・
（外国人の言い訳を許してください・・・orz）

皆様、いろいろ貴重な情報ありがとうございました。

・ファイル作成や更新
・デフラグ
等で変更されたくないってことですよね？
だったら不良クラスタとしてマークすれば目的は達成されると思いますが
いかがでしょうか？
不良クラスタのマークはFAT16なら0xFFF7、FAT32なら0x0FFFFFF7です。
FATの仕様書は以下のリンクからダウンロードできます。
http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx