4

人々が私のプロトコルをリバースエンジニアリングするのを防ぐことはできないことはわかっていますが、それを可能な限り困難にするために、あいまいなセキュリティアプローチを採用したいと考えています.

httpスタイル パケットを使用してネットワーク経由で通信するサーバー/クライアント システムがあります。

例：

Header
Attribute: Value
Attribute2: Other Value

Payload

クライアント以外がネットワークにアクセスするのをできるだけ難しくしたいと考えています。アセンブリを逆コンパイルすることで問題を解決する -ソースなしで別の実装を理解して作成することを非常に困難にするこのネットワーク仕様に対して、私ができるいくつかの良いことは何でしょうか?

私は、ある種の奇妙なハッシング アプローチや、難しい暗号化アルゴリズムを考えていました。

編集私は自分のアセンブリやソースコードを保護しようとしていません。たとえば、誰かが私のプロトコルを WireShark などで監視し、その情報に基づいて独自の実装を作成するのを防ごうとしています。

4

4 に答える 4

7

よし、3 つのケース:

  • ユーザーはサーバー コードにアクセスできず、クライアント コードにもアクセスできません。最も簡単な方法は、バイナリに保存されている事前生成された共有シークレットを使用し、暗号化/復号化することです。

  • ユーザーはクライアント コードまたはサーバー コードにアクセスできますが、両方にはアクセスできません。公開/秘密キー方式を使用します。公開鍵を使用して暗号化できますが、復号化するには秘密鍵が必要です。

  • ユーザーはクライアント コードとサーバー コードの両方にアクセスできます。

セキュリティを向上させたい場合は、この静的キーをセッションの開始時にのみ使用して、通信に使用される新しい共有シークレットを生成する必要があります。

編集: 実際には、より簡単で安全な解決策は、ssl と証明書を使用することです (これは、独自の暗号化を実装すべきではないというマントラです)。各証明書には秘密の秘密鍵が付属しています。ユーザーがアクセスできない限り、ピアが正確に正しい証明書を持っていることを確認すれば安全です。

于 2012-05-28T20:20:55.830 に答える
6

（MMOからの）いくつかのネットワークプロトコルを逆にしたことについて、私はあなたがあなたのプロトコルを非常に長い間保護することは決してないだろうとあなたに言うことができます、ごめんなさい。

あなたができる最善のことは：

  • カスタムアルゴリズムを使用して難読化します（既知のアルゴリズムよりも反転に時間がかかるため）。既知の暗号化スキームを使用しても、保護はまったく提供されません。
  • ノイズを追加。非常に、非常に混乱するようにしてください。まったく意味のないランダムな値を追加します。パケットには動的レイアウトを使用してみてください。フィールドを移動します。役に立たないパケットを送信します。まるでゴミのように。
  • プロトコルをバージョン管理して、2つの連続するバージョンに互換性がないようにします。それを行うのは難しいかもしれませんが、それ以降のバージョンごとにリバーサーが作業をやり直す必要があります。

しかし、これらは攻撃者を遅くする方法にすぎません。それは確かに彼らを止めるつもりはありません。

于 2012-05-28T20:22:43.580 に答える
2

次の 3 つの解決策があります。

  1. TLS。
  2. SSLv3。
  3. 何を調理しても。

1と2はすでに機能しています。

于 2012-05-30T00:05:52.257 に答える
0

また、C# でネットワーク プロトコルを作成中です。プロトコルを保護するために暗号化を利用しました。これが私が行った方法の支出です。これが役立つ場合があります。

  • クライアントがサーバーに接続するとすぐに、クライアントにランダムな UUID が要求され、クライアントはこの UUID をサーバーとクライアントの両方が知っているパスワードで暗号化します。
  • その後、サーバーまたはクライアントによって送信されるすべてのパケットは、その UUID をキーとして使用して暗号化されます。

「何か変なハッシング方法を考えていた」ということですが、ハッシングは通常、データの検証にしか使われません。つまり、途中で変更されていないことを確認するためです。

お役に立てれば。

于 2012-05-28T20:26:46.063 に答える