17

インターネットで販売するソフトウェアを作成する予定です。私はこれまでオープンソースしか作成したことがなかったので、クラッキングされてウェアーズとして配布されるのを防ぐ方法がまったくわかりません。クラックされていない、またはあまり役に立たないプログラムを 2 つ知っていることを念頭に置いて、信頼性の高い方法または信頼性の低い方法は次のようになると判断しました。

  1. サーバーに接続し、ライセンス情報とある種のハードウェア概要情報を提供します
  2. すべてが問題ない場合、サーバーは、その特定の PC にバインドされているプログラムのいくつかの重要な欠落部分を、たとえば 2 日間の使用制限とともに返します。
  3. その重要なものはハード ドライブに保存されないため、プログラムが起動するたびにダウンロードされます。プログラムが 2 日以上実行されると、データが再度ダウンロードされます。
  4. 異なるコンピュータから同じ情報が使用されている場合は、顧客アカウントを一時停止します

これについてあなたはどう思いますか?少し制限が厳しいように思えるかもしれませんが、最初は売り上げを減らし、最終的には貴重なキラー アプリを無料でダウンロードするようにした方がよいでしょう。とにかく、最初に、ユーザーが有料の場合に特定のJavaアプリのみを使用するようにする方法について、基本的な理論/チュートリアル/ガイドが必要なので、いくつか提案してください。

ありがとう

4

14 に答える 14

16

私は、保護されたJava ソフトウェアを販売する会社で働いています。

ユーザー認証のスキームについてはコメントしませんが、オンライン ライセンス チェックについてはコメントできます。

「2日間動作」することさえしないでください:それが私がほとんどのソフトウェアを海賊版にする方法です...仮想マシンは「時間に戻って」設定され、外部でファイアウォールされているため、もう「電話をかける」ことはありません(つまり、許可のみ一度サーバーに接続して試用キーを取得する必要があります)、常にソフトウェアを新しくインストールしてビンゴになった時点から再イメージ化されるため、30 日間の試用版 (または 2 日間の試用版) は生涯試用版になっています。なぜ私はこれを行うのですか?もちろん、アプリをより適切に保護する方法を学ぶためです ;) (わかりました、わかりました、私も楽しみのためにやっています)

私たちが商用 Java ソフトウェアで行っていることは、起動するたびにライセンスをチェックすることです。

私たちは何百人もの顧客を抱えていますが、誰もそれについて愚痴をこぼしたことはありません. 一度もありません。実行ごとに一意のクラスを生成します。これは実行ごとに異なります。これは、クライアント側でその起動に固有のものと、サーバー側で一度生成されたものの両方に依存します。

それに加えて、アプリを起動するたびにサーバーに接続することは、分析を収集するための優れた方法です。試用版のダウンロード率、試用版あたりの nb 平均起動数などです。そして、各 Web ページに Urchin/Google JavaScript トラッカーを配置するよりも厄介なことではありません。厄介です。

ソフトウェアがオンライン ライセンス チェックを実行することを人々に明確にするだけです。「オンライン ライセンス検証: OK/失敗」という巨大なチェックボックスがオンまたはオフになっています。以上です。人々は小切手があることを知っています。気に入らない場合は、劣った競合他社の製品を使用し、生活は良好です。

人々は有線の世界で生活することに慣れています。

インターネット接続がダウンしているため、GMail にアクセスできない頻度はどのくらいですか? インターネット接続がダウンしているため、FaceBook や SO にアクセスできない頻度はどのくらいですか?

ポイントは、サーバー側に応じてできるだけ多くの計算を行うことです。

  • ライセンスチェック
  • ユーザー設定を保存する
  • アプリによって生成されたデータのバックアップ

誰も文句を言いません。ユーザーの 0.1% が不満を言うことになりますが、いずれにせよ、これらのユーザーを望んでいません。彼らは、他のことについて不平を言い、アプリについてオンラインで否定的なフィードバックを投稿するユーザーです。実際にソフトウェアを使用してもらうよりも、ソフトウェアをまったく使用せず、常時接続のインターネット接続が必要であるという事実について不平を言うべきです (これはターゲット層の 99.99% であり、したがって彼らは不平を気にしません)。アプリに関連する他のことについて不平を言う。

逆コンパイルに関しては、有効なバイトコードを生成するコード フロー難読化ツールを使用しているが、.java ファイルから生成できない場合を除き、.class は通常、逆コンパイルして .java に戻すことができます (したがって、有効な .java ファイルを取得することはできません)。 )。

文字列の難読化ツールは、把握を困難にするのに役立ちます。

ソースコードの難読化ツールは、理解を困難にするのに役立ちます。

無料の Proguard のようなバイトコード難読化ツールを使用すると、把握するのが難しくなります (そして、より高速なコードが生成されます。特にモバイルの世界では顕著です)。

Windows/Linux のみを出荷する場合は、Excelsior Jet のような Java からネイティブへのコンバーターを使用できます (無料ではなく、スタートアップには少し高価ですが、.java ファイルを見つけることができないネイティブ コードを生成します)。

おもしろいことに、あなたのオンライン サーバーをいじろうとする人がいます... 約 30 人のベータ テスターの時点で、オンライン サーバーを海賊版にしようとしている人がいました (トライアルの一部であることがわかっています)。

于 2010-03-17T23:30:36.523 に答える
11

お断りして申し訳ありませんが、まず何を構築したいのかを考えてください。次に、あなたのアイデアが機能するだけでなく、ユーザーが海賊版を作成したいと思うほど愛されていることを証明する必要があります。第 3 に、アプリケーションを「安全」にするために費やした時間が実際にアプリケーションの価値に見合うものであることを確認する必要があります。

それを 1 ドルで売り、10 部しか売れず、100 時間かけてセキュリティを確保したとしたら、計算して、あなたの時間がそのわずかなお金の価値があるかどうかを教えてください。

ここでの重要なメッセージは次のとおりです。すべてがクラックまたはコピーされる可能性があります。最後に、これを行っている私たちよりもはるかに優れた人々がいます (iPhone クラッキング、デジタル TV、ゲームなど) が、特効薬を見つけた人はいません。唯一できることは、アプリケーションのクラックをより困難にすることです (多くの場合、使いやすさ、インストールの容易さ、およびいくつかの使用シナリオで手抜きをすることによって犠牲になります)。手間をかける価値があるかどうかを自問することは、常に良い出発点です.

于 2010-03-17T23:11:58.133 に答える
6

気にしないでください。

ゲーム業界は何十年もの間、著作権侵害と戦ってきました。通常、中央サーバーを使用するオンライン マルチプレイヤー ゲームをプレイするには、サブスクリプションが必要です。そのモデルは著作権侵害に対してかなり耐性があります。DRM への無数の試みにもかかわらず、他のほとんどすべてのゲームはひどく海賊版になっています。

アプリを作成する言語や、それを防ぐために使用するツールに関係なく、アプリはクラックされ、海賊版になります。あなたの DRM が実際に機能する場合、それを海賊版にしたであろう人々はそれを購入しません。さらに、正当なユーザーは、侵入的な DRM を持たない他の製品を好むでしょう。競合する製品がなく、あなたの製品に市場がある場合、誰かがそれを作成します。

于 2010-03-17T23:14:02.427 に答える
3

アプリケーションが特に Web ベースでない限り、ユーザーは、製品にアクセスするためにインターネット接続を要求するのが非常に面倒であることに気付くでしょう。あなたが提案していることは、すべての DRM システムがそうであるように、壊れない限りうまくいきます。知的財産を保護したいという気持ちは理解できますが、多くの企業を例にとると、これらのシステムは通常壊れているか、製品のパフォーマンスが大幅に低下しています。

于 2010-03-17T22:48:06.853 に答える
2

クラックされてウェアーズとして配布されるのを防ぐ方法がまったくわかりません。

まず、これが懸念される場合は、Java 以外の言語を選択することをお勧めします。これが、商用アプリの世界で C++ がまだ健在である理由です。実際の Java コンパイラをネイティブ exe に使用する予定がない限り、IP 保護の理由から Java を再検討します。

さらに言えば、C++ でさえクラッキングに耐性があるわけではありませんが、IP の保護とクラッキングは、2 つの別個の重要な問題です。

于 2010-03-17T22:50:51.657 に答える
1

これは、特に VM で何かが実行されている場合には、非常にトリッキーな作業です。私はあなたが正しい方向に考えているかもしれないと言います。難読化して変更を合理的に困難にすることで、組み込みのライセンス チェックを回避できなくなる可能性があります。

ただし、最終的には、アプリケーションが自己完結型であれば、常にクラック可能です。あなたが提供するサービスを使用するようにそれを構築できれば、おそらくそれを使用するように命じることができます.

于 2010-03-17T22:48:40.923 に答える
1

あなたの例には特定の弱点が見られますが、DRM は実装が困難 (不可能) であり、多くの場合、回避するのは簡単であるというコメントに加えて、ほとんどの人が既に入れています。

あなたの2番目のポイントで:

すべてが問題ない場合、サーバーは、その特定の PC にバインドされているプログラムのいくつかの重要な欠落部分を、たとえば 2 日間の使用制限とともに返します。

この 2 (または X) 日間の制限は、回避するのが非常に簡単である可能性が高く、これを見つけてパッチ (クラック) するのに数分しかかかりません。

本当に DRM モデルが必要な場合は、アプリケーションの大部分を Web サービスとして配置し、ユーザーからの常時接続を要求することが唯一の合理的な方法です。

これを試す前に、必ずExploiting Softwareを読んでください。DRM を試みる前によく考えてください。

于 2010-03-17T23:15:21.760 に答える
1

ジェフ アトウッド氏の言葉を借りれば、アプリをクラックするよりも、顧客が簡単に支払いを行えるようにする方がよいということです。言い換えれば、あなたは間違った問題を攻撃していると思います。あなたの製品を本当に簡単に購入できるようにしてください。

于 2010-03-17T23:15:34.567 に答える
1

ライセンス スキームを決定する前に、ゲーム Spore からの反動を調べます。彼らはそれを家に電話させ、非常に多くのインストールしか許可しませんでした. あなたは、人々が無料でそれを使用しているのを見るよりも、売り上げが少なくても構わないと言っていますが、あなたが求めるものには注意したいかもしれません. 私はスポアを本当に楽しみにしていました (そして私の子供たちもそうでした) が、DRM スキームのために購入することはありませんでした.

あなたが何をしても、プログラムが本当に価値がある場合は特に、非常に短い順序でクラックされます。

ライセンス方式を採用する場合は、ソフトウェアに実際にお金を払った人を罰しないように、シンプルで使いやすいものにしてください。また、3 年後にそのドメインの料金を払い続けたくない場合でも、顧客がソフトウェアを使い続けることができるように、テレフォン ホーム スタイルのチェックは避けたいと思います。

于 2010-03-17T23:16:30.587 に答える
1

コンテキストを考えると、現時点で最も効果的な保護の形態は、限定的なデモ/ライセンス キー アプローチになると思います。これにより、人々はアプリケーションに夢中になる時間を与えられ、喜んでお金を払いながら、カジュアルな使用を防ぐことができます。コピー。

アプリが大ヒットし、クラッカーが収益のかなりの部分を吸い上げることが証明されていることがわかったら、さらにチェックを追加できます。

考慮すべきもう 1 つの点は、アプリがどこで使用されるかということです。外出先で使用するためにノート PC に置くものである場合、ネットワーク接続は必須ではありません。

于 2010-03-17T23:43:37.647 に答える
0

CollbergとNagraの「SurreptitiousSoftware」を読む必要があります。この本は、ソフトウェア保護メカニズム(コードの難読化、透かし入れ、誕生マーキングなど)がどのように機能するかを理解するのに非常に役立ちます。

lorenzogが言ったように、完全なセキュリティは存在せず、ソフトウェアのセキュリティはソフトウェアベンダーと海賊の間の絶え間ない競争のようなものです。

できるだけ多くの攻撃者(ほとんどがスクリプトキディであることを忘れないでください)がキラーアルゴリズムや秘密のデータを「盗む」のを防ぐために、安価な難読化変換を使用する必要があります(そのため、パフォーマンスが低下することはありません)。

セキュリティをさらに強化したい場合は、アルゴリズムを作成し、コピーに透かしを入れて、作成物を漏らした人を見つけることができます。ただし、そうしても、ソフトウェアが100%保護されているわけではありません。さらに、これらのメカニズムを追加するために費やす時間は、努力する価値がない場合があります。

これらの概念は、私が前に述べた本で本当によく説明されており、読む価値があります。

于 2010-03-17T23:56:25.483 に答える
0

これは私が今まで聞いた中で最も厳しい DRM の 1 つであり、ユーザーはそれを嫌うでしょう。

また、言語の性質上、優れたJava逆コンパイラがたくさんあることに注意してください.DRMを処理するプログラムの領域を見つけて、バイパス/無効にしてから再コンパイルすることできます.再コンパイルは非現実的です)...そのため、ハッカーが成功するのを防ぐために、コードをできるだけ複雑に実装するために邪魔をする必要さえあります. (これは、彼らが持っている可能性のあるコード難読化ツールの 1 つを使用して行うことができます。)

于 2010-03-17T23:01:57.683 に答える
0

インターネット アプリケーションである限り、そのように制限できます。プログラムをクラックすることを除けば、これはリプレイ攻撃を除いてうまく機能します。

たとえば、あなたのサーバーに送られるトラフィックをキャプチャし、そのトラフィックを毎回自分のプログラムに単純に再生できれば、それでも問題ありません。たとえば、独自の「Web サーバー」を作成し、プログラムがサーバーの代わりにヒットするようにすることができます。

于 2010-03-17T23:46:43.900 に答える
0

十分な評判ポイントがあれば、この質問に反対票を投じます。商用ソフトウェアの保護は、さまざまな理由から、時間、お金、および労力の無駄です。購入する価値のあるソフトウェアを作ることに集中してください。あなたのソフトウェアが著作権侵害者による広範なシードを維持するほど人気が​​ある場合、その時点で著作権侵害について心配する必要さえないほど十分に成功している可能性があります。いずれにせよ、クラッカーは主に楽しみのためにソフトウェア保護をクラックします。保護が強化されればされるほど、より優れた課題が提示され、攻撃者はより多くのことを求めます。最善を尽くしても数千ドル、数か月かかり、数日でクラックされます。

于 2010-03-29T01:26:24.010 に答える