- - PR -
実行ファイルへのアクセス制限
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-08-28 12:50
.net初心者です。
プログラム内で、あるファイルを開く際に、FileShare.Noneにすると閉じるまで 他プロセスは、そのファイルへのリードも拒否できます。 static void Main(string[] args) { FileStream fs = new FileStream(@"c:\hoge.txt", FileMode.Open, FileAccess.ReadWrite, FileShare.None); System.Threading.Thread.Sleep(10000); fs.Close(); } 例えば、A.exeという.netプログラムを実行し、実行中は、上記のような、他プロセス のリードすら拒否することは可能でしょうか? A.exe内の処理で制御するというよりは、.netのvmへのパラメータで 実現するのではないかと思っているのですが、あれこれ調べても分かりませんでした。 ご存知の方いらっしゃいましたら、お教え頂けないでしょうか。 宜しくお願いします。 | ||||||||||||
|
投稿日時: 2008-08-28 17:19
未検証ですが、起動直後に自分自身を FileShare.None でオープンしてみるとか
_________________ C#と諸々 | ||||||||||||
|
投稿日時: 2008-08-28 17:43
よこけんさま
私もそれは試してみました。 結果として、Open時にIOExceptionが発生しました。 ”別のプロセスで使用されているため、プロセスはファイル'A.exe'にアクセスできません。” となります。 私的には、System.Security.Permissions辺りが怪しいと思って調べてはいるのですが まだ、解決できません。 | ||||||||||||
|
投稿日時: 2008-08-28 22:08
直接回答ではないのですが、念のため確認です。
質問題意は、EXE自身へのアクセス拒否手法ですが、 ひょっとして、その目的(アクセス拒否したい目的)が 【同一マシンからの同一EXE二重起動防止】 だったりします? 穿った見方ですが、もし 目的がそうなら、 簡単に対処できますが。 また、同一マシンではなくても、exeがネットワークドライブ上にあって、 【複数マシンからの同一EXEが同時稼動防止】 という目的であれば、DBを使うなどの対処があるかと。 かなり、曲がって見ている(邪推しすぎ?)ますが、 もし、目的がそうなら、手段はもっとシンプルな方法があるかと。 | ||||||||||||
|
投稿日時: 2008-08-28 22:22
FileAccess.ReadWrite で開いてませんか?
次のコードで試してみましたが、成功しました
_________________ C#と諸々 | ||||||||||||
|
投稿日時: 2008-08-28 23:56
platiniさま
私の説明不足でした。多重起動制御が目的ではありません。 簡単にやりたいことを説明すると以下のようなことになります。 1. .netアプリは簡単にリバースエンジニアリングできる。 難読化しても心配。 2. 対策として、 1)win32アプリで.netアプリを内包する仕組み。 → .netアプリのロードやentrypointの変更、PEヘッダの仕組み解析などに 時間がかかりそうなので、ペンディング。 2).netアプリをwin32アプリで暗号化。複合化するwin32アプリと共に暗号化した .netアプリを配布。 →簡単そうなので、チャレンジ。 3. 2)はwin32アプリで.netアプリを複合化して、win32アプリ内CreateProcess()で .netアプリを起動。 →.netアプリ起動中は、絶好のクラックチャンス。 4. クラック対策として、.netアプリ起動中は、ユーザからの、ファイルリードや、 コピーも拒否したい。終了時には、.netアプリの削除で万全か!? ということで悩んでおりました。 よこけんさま 私のやり方が悪かったようです。 デバッグ実行だと駄目なのですね。リリースビルドで実行すると成功することを 確認できました。 ありがとうございました。 完全他力本願と非難されそうですが、上記 2. 1) win32アプリで.netアプリを内包し、win32アプリ起動で内包してある.netアプリまで 起動させる方法や、情報お持ちの方おられましたら、情報の提供お願いできますでしょうか。 図々しくて申し訳ありませんが、よろしくお願いします。 | ||||||||||||
|
投稿日時: 2008-08-29 07:27
例えば、アプリ(あるいは削除用の監視アプリ)をタスクマネージャから強制終了させられた時はどうするんですか?
ファイルを削除するタイミングを逸して残るはずですよね。 また、対象のフォルダのセキュリティ設定で書き込みや削除の拒否を設定された場合、ファイルを消せない状態に仕立て上げることができます。 さらに途中で電源を強制的に落とすとかでも可能です。 結局のところ、完璧な対策は無理じゃないかという点、それでも今の方針で続けるのかという点で疑問を持っています。 [ メッセージ編集済み 編集者: Azulean 編集日時 2008-08-29 07:36 ] | ||||||||||||
|
投稿日時: 2008-08-29 09:45
Azuleanさま
これは、win32アプリ―.netアプリ間のプロセス間通信で解決しようと考えてました。
これは、考慮していなかったです。確かに電源断は対処しようがないですね。
Azuleanさまのおっしゃるとおりで、ソフトウェアである時点で完璧は不可能だと思っています。 そういった意味ではwin32アプリが存在している辞典で、有識者であれば、逆アセンブルしてアセンブラレベルである程度解析は可能だと思います。 ここからは、確率の問題になると思うのですが、 マニュアルに、.netFrameworkをインストールしてください。と書かれていた場合、 配布ファイルは、おそらく.netアプリだろうと判断するでしょう。 そこで、解読しようとした場合、.netアプリの場合、難読化されていたとしても、 Reflectorで中をのぞくことが可能です。 それが、実はwin32アプリから暗号化したファイルを複合化して.netアプリを呼び出している場合、そこまで想像できる人は何%いるでしょうか? 仮に気づいたとして、恐らく次に考えることは、起動中の.netアプリプロセスからファイルを特定し、それをコピーし、後で解析しようと考えると思います。 そこで、起動中の実行ファイルをコピーできなかった場合、PCの電源断などを考える人は何%いるでしょうか? そう考えた時、いきなり.netアプリを配布してしまうと、解析しようと思えば100%の確率で可能な事象を、かなり低下させることができると考えています。 以上、長々と書いてしまいましたが、私の考えを書いてみました。 |