3

間もなく有料の静的ライブラリを出荷する予定ですが、開発者がライブラリをコピーするのを防ぐために、何らかの形のコピー防止機能を組み込むことができるかどうか疑問に思っています。

理想的には、ライブラリが開発者のマシンに不正にコピーされた場合に限り、ライブラリが実行可能ファイルにリンクされないようにします。これは可能ですか?

あるいは、ライブラリの不正なコピーにリンクされたアプリケーションが単に機能しなかった場合でも、許容できる可能性があります。ただし、これによってこれらのアプリケーションのユーザーに負担がかからないことが非常に重要です(ライセンスキーの入力、ドングルの使用、インターネット接続の要求など)。

ライブラリはC++で記述されており、WindowsやMacを含む多くのプラットフォームを対象としています。

オプションはありますか?

4

9 に答える 9

9

私は、絶対確実な保護は単に不可能であるという他の回答に同意します。しかし、穏やかなナッジとして...

ライブラリがプリコンパイルされている場合は、APIでカスタムライセンス情報を要求することにより、過度の不正使用を防ぐことができます。

次のような関数を変更します。

jeastsy_lib::init()

に:

jeastsy_lib::init( "Licenced to Foobar Industries", "(hex string here)" );

ここで、最初のパラメーターは顧客を識別し、2番目のパラメーターはMD5または最初のパラメーターソルトを含む他のハッシュです。

ライブラリを購入するときは、これらのパラメータの両方を顧客に提供します。

明確にするために、これは賢くて野心的な人にとっては簡単に回避できる保護です。これを著作権侵害への道のスピードバンプと考えてください。これにより、潜在的な顧客に、ソフトウェアを購入することが最も簡単な方法であると納得させることができます。

于 2010-01-10T22:36:49.507 に答える
7

C++静的ライブラリはひどく悪い再配布可能です。

これはボットの接線ですが、ここではIMOについて言及する必要があります。呼び出し元と一致する必要がある多くのコンパイラオプションがあります。

  • Ansi / Unicode、
  • 静的/動的CRTリンク、
  • 例外処理の有効化/無効化、
  • メンバー関数ポインターの表現
  • LTCG
  • デバッグ/リリース

これは最大64の構成です。

また、C ++コードがプラットフォームに依存しない場合でも、プラットフォーム間で移植性はありません。同じプラットフォーム上の将来のコンパイラバージョンでも機能しない可能性があります。LTCGは巨大な.libファイルを作成します。したがって、いくつかの選択肢を省略できる場合でも、ビルドと配布のサイズが非常に大きく、ユーザー向けの一般的なPITAがあります。

これが、静的ライブラリのみに付属するものを購入することを検討しない主な理由です。ましてや、あらゆる種類のコピー防止機能を追加するものはありません。


実装のアイデア

Shmooptyの提案よりも優れた基本的なメカニズムは考えられません。

さらに、ビルドに「透かし」を入れることができるので、「野生の」ライブラリを検出した場合、そのライブラリを誰に販売したかを判断できます。(しかし、あなたは何をするつもりですか?潜在的に無実の顧客に怒った電子メールを書きますか?)また、これにはいくらかの努力が必要です。実行に影響を与えない簡単に見つけられるバイトのシーケンスを使用してもあまり役に立ちません。

LIBの「アンパッカー」ツールから身を守る必要があります。ただし、リンカは未使用の関数を削除できるはずです。


一般的な考え

適切な保護メカニズムの実装には細心の注意と創造性が必要ですが、追加のサポートコストを発生させず、厳しい社会的決定を必要とするメカニズムはまだ1つもありません。コピー防止に費やされる時間は、製品の改善に費やされない時間です。C ++コードの市場はそれほど大きくはありません。顧客が支払う必要のある作業は、たくさんあると思います。

私がコードを購入するとき、私はドキュメント、サポート、ソースコード、およびその他の「将来の証拠」の兆候に対して喜んで支払います。ライセンスについてはそれほど多くありません。

于 2010-01-10T23:29:22.160 に答える
4

理想的には、ライブラリが開発者のマシンに不正にコピーされた場合に限り、ライブラリが実行可能ファイルにリンクされないようにします。これは可能ですか?

リンク時にライブラリが「不正にコピー」されたかどうかをどのように判断しますか?

リンカが機能するときは、コードが実行されていないことを覚えておいてください。

したがって、コードが実行されていないことを考えると、コンパイル時またはリンク時に何も実行できません。そのため、完全に無関係なターゲットマシンから、ライブラリがリンクマシンに不正にコピーされたかどうかを判断しようとすることになります。そして、エンドユーザーに「インターネットアクセスが必要」などの負担を課すことをいとわなかったとしても、2つの状況を区別できるようにする方法はまだわかりません。

私の結論は、ファジーロリポップの「人々がそれを購入したくなるほど便利なものを作る」という提案は、コードライブラリを「コピープロテクト」するための最良の方法であるということです。

于 2010-01-10T22:28:18.617 に答える
2

コピー防止、この場合、実行保護は定義上「ユーザーに負担をかけます」。それを回避する方法はありません。コピー防止の最良の形態は、有用な人々がそれを購入せざるを得ないと感じるような何かを書くことです。

于 2010-01-10T22:22:41.810 に答える
0

あなたはあなたが望むことをすることができません(不法に作品をコピーする人々以外の誰にも負担をかけない完全なコピー防止)。

リンク時に標準のリンカーを使用してコードを実行する方法はないため、その時点で問題がないかどうかを判断する方法はありません。

それは実行時間を残します、そしてそれはエンドユーザーに何らかの方法で検証することを要求することを意味します、そしてそれはあなたがすでに非スターターであると決定しました。

唯一の選択肢は次のとおりです。そのまま出荷し、開発者がコピーしすぎないようにするか、独自のリンカーを作成して、人々にそれを使用してもらうようにします(明確でない場合に備えて:それは機能しません。特別なリンカーを必要とするライブラリを購入する開発者はいないでしょう。

于 2010-01-10T22:35:22.177 に答える
0

高価なフレームワークを公開することを計画している場合は、FLEXlmの使用を検討するかもしれません。

私はそれらとは関係がありませんが、シリコングラフィックスハードウェアをターゲットにすることが多いさまざまな高価なフレームワークでそれを見てきました。

于 2010-01-10T22:59:11.457 に答える
0

いくつかのアイデア...(これらには明らかなはずですが、いくつかの大きな欠点があります)

コンパイル時の場合:ライブラリファイルを共有に配置し、販売先の開発者にのみファイルのアクセス許可を付与します。

実行時の場合:特定のマシンでのみ機能するようにライブラリをコンパイルします。UIDやMACIDなどを確認してください

于 2010-01-10T23:17:09.253 に答える
0

有料の静的ライブラリをまもなく発送します

あなたの質問に対する正解は次のとおりです。あなたがそれを必要としていることを証明するまで、コピー防止を気にしないでください。

あなたは「まもなく有料の静的ライブラリを出荷する」と言っています。自分のテクノロジーを盗もうとする人がいることを証明しない限り、コピー防止を実装することは重要ではありません。「盗む人がいる」という不安感は、盗まれる証拠ではありません。

起業の最も難しい部分は、人々がお金を払う製品を作ることです。あなたはまだそれをしたことを証明していません。エルゴコピー防止は関係ありません。

あなたの製品に価値がないと言っているのではありません。売ろうとしないと価値があるかどうかわからないと言っています。

そして、それを売っても、人々がそれを盗むかどうかはわかりません。

これが、優れたプログラマーであることと優れたビジネスオーナーであることの違いです。

まず、誰かがあなたの製品を盗もうとしていることを証明します。次に、誰かがそれを盗もうとした場合は、コピー防止を追加して、製品を改善し続けます。

于 2016-02-05T19:01:07.927 に答える
0

私はこれを一度だけしました。これが私が使った方法でした。絶対確実というわけではありませんが、良い妥協点だと感じました。それはドリュー・ドーマンの答えに似ています。

ユーザーが自分の電子メールとその電子メールにリンクされたキーを提供することを要求する初期化ルーチンを提供することをお勧めします。次に、製品を使用しているすべての人が電子メール情報を表示できるようにします。

このメソッドは、AfterEffectsのプラグインを作成するときに使用するライブラリで使用しました。初期化ルーチンは、プラグインの[バージョン情報]ダイアログに表示されるメッセージを作成し、このメッセージに特定の電子メールを表示させました。

私の目には、この方法の利点は次のとおりです。

  1. クライアントは、自分が作成していない製品に自分の電子メールを関連付けたくないため、自分の電子メールとキーを渡す可能性はほとんどありません。

  2. 彼らはバーナーメールでサインアップすることでこれを回避することができますが、そうすると彼らは自分たちが書いた製品に関連付けられたメールを受け取らないので、これもまたありそうもないようです。

  3. バーナーメールのあるバージョンが配布された場合、人々はそれを試して、それを使用したいと思うかもしれませんが、メールに関連付けられたバージョンが必要なので、コピーを購入する可能性があります。無料広告。あなたもこれを自分でやりたいと思うかもしれません。

また、私が会社にプラグインを提供するときに、私の長年の専門知識に基づいて、プラグインを自分で作成するために内部プログラマーにライブラリを提供できないようにしたかったのです。これを行うために、プラグイン名もキーにリンクしました。したがって、キーは特定のプラグイン名と開発者の電子メールに対してのみ機能します。

ドリューの答えを拡張するには、これを行うには、ユーザーがサインアップしたときにユーザーの電子メールを受け取り、最後に秘密の文字セットをタグ付けしてからハッシュします。ユーザーにハッシュを提供します。文字の秘密のセットはすべてのユーザーで同じであり、ライブラリに認識されていますが、電子メールによってハッシュが一意になります。ユーザーが電子メールとハッシュを使用してライブラリを初期化すると、ライブラリは文字を追加してハッシュし、ユーザーが提供したハッシュと結果を照合します。このように、すべてのユーザーにカスタムビルドを行う必要はありません。

結局、これよりも複雑なものは無駄だと感じました。私のライブラリを本当にクラックしたい人は、私がそれを守るよりも、おそらくそれが得意だからです。この方法は、カジュアルな海賊が私の図書館を簡単に利用するのを防ぐだけです。

于 2019-03-14T13:22:21.333 に答える