DirectInputのキーボードがキーロガーに？

質問

現在
フレームを単位としてキーボードの状態変化をリプレイデータとして保存出来る
DirectXを使用したゲームを作っているのですが

使用中のセキュリティソフトが
DirectInputでGUID_SysKeyboardを使ってGetDeviceStateでキーボードの入力情報を操作しようとすると

「キーロガーの疑いがあります」と言ってきます。
現在のところはデフォルト動作（？）で許可はしているようですが

WindowsAPIのウインドウメッセージでキーボードからの入力情報を操作しながら
同時にジョイパッドからの入力情報はDirectInput経由で操作
としていた時は出てなかった気がするので

たぶんDirectInputでキーボードの入力情報をいじろうとした場合に出るのでは？
と思うのですが

SetCooperativeLevelで指定しているフラグは
DISCL_FOREGROUND|DISCL_NONEXCLUSIVE　
ですが、これで問題ないと考えていますし、害のある動作をするつもりは毛頭なく

また、WindowsAPIからジョイパッドの操作情報を制御する、という事はまだ試していませんが、聞いた話では2つまでしか受け取れない（？）ようで、一つのPCで少なくとも4人ぐらいまでは同時プレイできるゲームにしたいので
それがあってるなら、出来ればDirectInputがよく

そして、ジョイパッドとキーボードで使うAPIの系統を変えるよりかは、DirectInputならDirectInputで統一、としておく方がよりシンプルで直感的なコードになりやすいと思うので、出来ればそうしたいのですが

セキュリティソフトを全くいじらずに

これを防ぐ方法はないでしょうか？

あるいは、それを望む場合は
（これが「結構細かい話でこの場合一般的に言って、ということはない」というのであれば）

・たぶん、キーボードについてはDirectInputを使ったらその時点で無理ではないか
・よって、その表示を防ぐにはキーボードについてはWindowsAPIサイドから、普通のウインドウメッセージを使ってやるべき

ということでしょうか？

回答No.1

chie65535 · ベストアンサー

＞キーボードの状態変化をリプレイデータとして保存出来る

それって「キーロガーそのもの」でしょ。

キーロガーってのは「何のキーを、どういう風に押したか、ログを取るモノ」なんだから。

なので、キーロガーとして警告されるのは当たり前。

＞害のある動作をするつもりは毛頭なく

害があるかどうかは無関係。

「キーの押下を監視して、押下状態をファイルなどに書き出す」と言う処理を行えば、セキュリティソフトが反応します。

因みに「キーボードの監視」では、リプレイは上手く行きません。

リプレイ保存は「キーやパッドの状態を読みに行っている部分」で行わないと失敗します。

保存するデータは「フレーム番号」と、キーやパッドの状態ではなく「プレーヤーがどう動くかの内部コード」にします。

で、リプレイ再生する場合は「キーやパッドの状態を読みに行く代わりに、リプレイデータを読み込んで、プレーヤーを動かす」のです（その際には「このフレームになったら」ではなく「このフレームを超えたら」にしましょう。処理落ちで「フレーム番号が飛ぶ」と、再生すべきリプレイデータが「すっ飛ばされて」変な動作をします）

擬似的にキーやパッドの変化状態をウィンドゥメッセージに突っ込んでも、メッセージが取り溢されたり、メッセージキューに空きが無くてメッセージを突っ込めないなどで、思った通りにはリプレイされません。

実際にゲームをプレイしていても、処理落ちなどで「押した筈のキーが無視される」って事が起こるので、キーやパッドの状態変化を擬似生成すると、確実に失敗します。

そういった訳で、キーとパッドは「単純にセンスするだけ」にしましょう。状態変化を保存なんかしちゃいけません。

お礼

ご回答ありがとうございます。
WindowsAPIで同じような記録方法をとった場合は、表示されなかったことと
聞く話では別のゲームでもそういう事がある、というケースがある
ということから、DirectInputでキーボードの判定を使ったことが鍵ではないかと思ったのですが

＞「プレーヤーがどう動くかの内部コード」にします。

ファイルサイズ縮減のため

私が作成したリプレイデータの保存方法では
「フレーム番号」のかわりに「変化があった前のフレームとの差分数」にしてあり（そこについてはMIDIファイルなどで使われている方法である、ビットフラグを利用した可変長にするか、4バイト程度の固定にしてリプレイデータに圧縮をかけるコードを書くかはまだ実験段階ですが）

ボタンであればそのボタンのONOFFが切り替わった場合インデックスのみがアウトプットされるという仕組みにしてあるのですが

その単位はフレームにしてあります。

逆に言うと、記録時はDirectInputを使うならば、わざわざ1フレームごとにGetDeviceStateしに行ってチェックするという事になります。

ファイルサイズの無駄な膨張を防ぐためには変化のみを記述するのが良いのではと考えたのですが

つまりは

この方法そのものに問題がある、という事でしょうか？

補足

なお、BGMの再生のための読込時間などの制御への対処はまだですが、それを除き
完全に同じ動きをするリプレイというのは出来ています。
（フレームに従って動くので、プログラムミスがなければ当然と言えば当然ですが）

「プレーヤーがどう動くかの内部コード」が、どこまでのことによるのか…ということでしょうか？

回答No.2

super_raumen

教えてgooでは質問者が自ら書き加えたくても
出来ないようになっているため

別IDを作ることで、経過報告のスペースを確保させていただきます。
質問者です。
（自身の別IDにつけるのは「お礼」ではなく「補足」のみで、ベストアンサーに選ぶこともありません。）

補足

とりあえずDirectInputを使う事を控えることで対処としていましたが
アップグレードしたら
DirectInputを使っても、私のソフトでも他のソフトでも「キーロガーの疑い」が出なくなったようです。

まぁ動作的には「キーロガー」と言えないこともないかもしれませんが
やはり倫理的、内容的には誤検出に近いと言えるレベルだったと思うので

一応
かなり最終的な段階になって
必要になったら対象としたい環境でいくつかテストさせてもらって

どっちの方法でも出来ることはできますし

光明も見えたので、解決とさせていただきます。