0

私は、iOS クライアント SDK が静的ライブラリではなくコードとして開発者に配布されるクライアント/サーバー SDK プロジェクトに取り組んでいます (この配布方法にはビジネス上の理由があります)。一部の開発者がクライアント SDK コードを変更していると思われる状況に遭遇しました。クライアント SDK を更新して、これをより積極的に検出したいと考えています。

私が考えたのは、コンパイル時にコード ファイルのチェックサムを何らかの方法でチェックサムし、クライアント SDK がサーバーと対話するときにそのチェックサムを SDK バージョンとともに報告することでした。クライアント SDK をリリースする前に、弊社側で各バージョンのチェックサムを記録し、クライアント SDK チェックサムがそのバージョンに対して正しくない場合、サーバーに送信されたものはすべて拒否します。

ここでいくつか質問があります。

  1. コンパイル時にクライアント SDK の Objective-C コードを控えめにチェックサムするにはどうすればよいですか?
  2. 私の一般的な目標を達成するためのより良い方法はありますか?
4

2 に答える 2

3

コンパイル時にクライアント SDK の Objective-C コードを控えめにチェックサムするにはどうすればよいですか?

あなたが想像している/望んでいるように、それは不可能だと思います。ソースコードにアクセスできれば、ハードコーディングされたチェックサムを含め、あらゆるものを変更できます (とにかくチェックコードにパッチを当てることができます)。

私の一般的な目標を達成するためのより良い方法はありますか?

ええと...ライブラリをクローズドソースとして配布できない場合は、そうではありません...ライセンスでコードを変更しないことを要求し、サーバーを使用してブロックする必要があるかもしれませんコード。

それにもかかわらず、なぜコードの変更をそれほど気にするのですか?

于 2013-01-26T19:11:39.320 に答える
0

このアプローチは、何もないよりも少し安全性を高めます。

  1. コンパイル時にライブラリ ソース コードの暗号化ハッシュを生成するビルド ルールを追加し、結果をライブラリにビルドします。
  2. ライブラリのバージョン番号とともにハッシュをサーバーに送信します。
  3. ハッシュとバージョン番号がサーバーで一致することをサーバーで検証します。

変更されていないバージョンの事前に計算されたハッシュを使用してライブラリのスクリプトを単純に構築できるため、断固たる攻撃者に対しては安全ではありません。おそらく、プロセスをある程度難読化できます。

于 2013-01-26T19:51:16.980 に答える