小規模ベンダー向けのソフトウェア保護

Question

これは、ある時点で私たち全員が考慮しなければならない問題です。

長年、多くのアプローチを経て、私は一般的に声明に同意する傾向があります。 <！> quot;数百人以上が使用する保護されたソフトウェアについては、クラックされたバージョンを見つけることができます。これまでのところ、すべての保護スキームは改ざんされる可能性があります。<！> quot; 雇用主は著作権保護ソフトウェアの使用を強制していますか？

さらに、このテーマについて投稿するたびに、誰かが思い出させてくれます。 <！> quot;まず、どのような保護を採用しても、真に専用のクラッカーが最終的にすべての保護バリアを通過します。<！> quot; お金にとって最高の価値は何ですか単一の開発者向けのc＃コード保護

したがって、これら2つの広く真の免責事項に抗して、<！> quot; protection <！> quot;！

私はまだ、熟練したクラッカーの時間と注意を正当化する可能性が低い小さなアプリの場合、保護は価値のある運動であると感じています。

何をしても、クラッカーがアプリケーションにパッチを適用してIFステートメント（jmp）の結果を切り替えることができれば、世界中のすべてのパスワードとドングルが役に立たないことは明らかです。

だから私のアプローチは、次のような製品を使用して仮想化でコードを難読化することです。 http://www.oreans.com/codevirtualizer.php 私はこの製品にとても満足しています。私の知る限り、それは打ち負かされました。 PEcompactで実行可能ファイルを圧縮することもできます 他に経験がある人はいますか？

EXEcryptorに問題があるだけ http://www.strongbit.com/news.asp このサイトでさえも頭痛の種です。 コンパイルされたアプリは、WMI呼び出しを行うとクラッシュします。

このアプローチにより、コードの小さなセクションを難読化で囲み、セキュリティチェックなどを保護できます。

Iアプリケーションはサーバーからのデータを定期的に必要とするため、ユーザーが長期間オフラインで使用するのは意味がないため、オンライン承認アプローチを使用します。定義上、アプリはクラックされても、その時点では価値がありません。

したがって、単純な暗号化されたハンドシェイクは十分に良いです。難読化保護の範囲内で時々チェックするだけです。ユーザーが別のマシンにアプリをインストールすると、起動時に新しいIDがアップロードされ、サーバーは古いIDを無効にして新しい承認を返します。

また、コンパイルされたアプリのハッシュを使用し、起動時に1ビットが変更されているかどうかを確認し、アプリ内でアプリをファイルとして（読み取りLOCKで）開いて、起動後に誰も変更しないようにします。

すべての静的文字列は.exeファイルで明確に表示されるため、エラーメッセージなどを一般的にしようとします。文字列<！> quot; Authorization failed <！> quot;は見つかりません。どこでも。

メモリダンプから保護するために、単純なテキスト難読化手法（すべての文字のXORなど）を使用します。これにより、メモリ内のプレーンテキストデータを変数などと区別しにくくなります。

もちろん、本当に機密性の高いデータにはAESがあります。テキストのカウンターモードが好きです。これは、空白のシーケンスのような基礎となるデータを明らかにする繰り返しシーケンスがないためです。

しかし、これらすべての手法では、キーまたは初期化ベクトルをメモリからダンプできる場合、またはIFステートメントがバイパスされる場合、すべてが無駄になります。

私は条件文ではなくswitch文を使用する傾向があります。次に、実際に実行する関数ではなく、基本的に行き止まりの2番目の関数を作成します目的のタスク。

別のアイデアは、変数を追加してポインターをコーディングすることです。変数は承認の結果です（通常はゼロ）。これにより、ある時点でGPFが発生することは避けられません。 いくつかの下位レベルの認証が失敗した後、最後の手段としてのみこれを使用します。そうしないと、実際のユーザーが遭遇する可能性があります。その後、ソフトウェアの評判が低下します。

どのようなテクニックを使用していますか

（これは何かを実装するメリットを議論するスレッドではありません。何かをすることを決めた人のために設計されています）

Answer 1

xslに同意しません。

収益を保護するためではなく、コードを保護します。ライセンスがない場合に使用する人は、おそらくとにかくお金を払わないでしょう。

代わりに、私たちの顧客が私たちのソフトウェアに行った投資を保護するためにそれを行います。当社のソフトウェアを使用することで、市場での競争力が高まり、他の企業が支払いをせずにアクセスできるようになると、不当な優位性が得られると考えています。つまり、ライセンス費用のオーバーヘッドなしで競争力を高めます。

私たちは、自家栽培の保護が有効なユーザーにとってできるだけ目立たないように非常に注意しており、この目的のために、これに影響する可能性のある既製のソリューションを「購入」することは決して考えません。

Answer 2

ソフトウェアをクラックするのに数百人のユーザーは必要ありません。シェアウェアが何度もクラックされることに悩まされたので、実験として、Magic Textbox（これはテキストボックスを含むフォームでした）と呼ばれるプログラムを作成し、シェアウェアサイトにリリースしました（独自のPADファイルとすべてを持っていました） ）。 1日後、Magic Textboxのクラックバージョンが利用可能になりました。

この経験から、基本的なコピー保護以外の方法でソフトウェアを保護しようとするのをあきらめました。

Answer 3

私は個人的にここで説明したコードテクニックを使用します。これらのトリックには、正当なエンドユーザーの生活をより困難にすることなく、海賊を不便にするという利点があります

しかし、より興味深い質問は<！> quot; what <！> quot;ではなく、<！> quot; why <！> quot;です。ソフトウェアベンダーがこの種の演習に着手する前に、脅威モデルを構築することが非常に重要です。たとえば、低価格のB2Cゲームの脅威は、高価値のB2Bアプリの脅威とはまったく異なります。

パトリック・マッケンジーは、 4種類の潜在顧客の分析など、いくつかの脅威について説明します。ビジネスモデルの保護について選択する前に、独自のアプリに対してこの脅威分析を行うことをお勧めします。

Answer 4

自分の前にハードウェアキーイング（ドングル）を実装したことがあるので、この問題にまったく慣れていないわけではありません。実際、私はそれに多くの考えを与えました。あなたのクラッカーが行っているように、著作権法に違反している人には同意しません。ソフトウェアのコピーを合法的に取得したくない場合は、この方法を使用してください。ソフトウェアの著作権を自分で侵害することはありません。言われていること...

私は本当に<！> quot; protect <！> quotという言葉が嫌いです。ここで使用します。保護しようとしているのは、コントロールだけです。ソフトウェアを保護していない 。ユーザーと同様に、ソフトウェアはどちらの方法でも問題ありません。

人々があなたのソフトウェアをコピーしたり共有したりするのを防ぐのは非常に神聖なPITAである理由は、そのような活動を防ぐことは不自然だからです。コンピューターの概念全体はデータのコピーを中心に展開され、有用なものを共有したいのは人間の性質です。あなたが本当に主張すれば、あなたはこれらの事実と戦うことができますが、それは生涯の戦いになります。神は人間を別様に作っていませんし、物をコピーできないコンピューターを買っているわけでもありません。たぶん、常に彼らと戦うよりも、コンピュータと人々と 一緒に働く方法を見つけた方が良いでしょうか？

私は、大半のプロのソフトウェア開発者とともに、ビジネスを行うために開発されたソフトウェアを必要とする会社にフルタイムで雇われています。<！> quot;ソフトウェア製品<！> quot ; <！> quot; sell <！> quot;への人工的な不足ユーザーに。一般的に有用なもの（ここでは<！> quot; competitive Advantage <！> quot;とは見なされません）を書いた場合、フリーソフトウェアとしてリリースできます。 <！> quot;保護<！> quotなし;が必要です。

Answer 5

一部のリンクから：

説明しようとしたコンセプトは、<！>＃8220; crack spread <！>＃8221;と呼ばれるものです。 <！>＃8217;アプリケーションにクラック（またはkeygen、または海賊版シリアルなど）が存在することは問題ではありません。重要なのは、クラックにアクセスできる人の数です。

シリアル番号を確認する場所/タイミング：起動時に1回確認します。多くの人は、<！>＃8220;あらゆる種類の場所にチェックイン<！>＃8221;と言って、誰かがチェックを外してクラックするのをより困難にします。クラッカーを特に扱いたくない場合は、インラインコードを使用してあらゆる種類の場所をチェックインし（DON <！>＃8217; TをすべてSerialNumberVerifier.classに外部化します）、可能な場合はマルチスレッド化してハードにします失敗したときも認識します。しかし、これはクラックを不可能にするのではなく、難しくするだけであり、一般的にクラッカーを倒さないことが目標であることを忘れないでください。クラッカーを倒しても、かなりの金額にはなりません。ほとんどの場合、通常のユーザーを倒すだけでよく、通常のユーザーはデバッガーにアクセスしたり、デバッガーを使用したりすることはできません。

あなたが家に電話をかける場合は、ユーザー情報を家に電話をかけ、サーバーの出力としてシリアル番号を受け入れる必要があります<！>＃8217;シリアル番号とブール値などを出力として受け入れます。つまり、キー検証ではなくキー注入を行う必要があります。鍵の検証は最終的にアプリケーション内で行われる必要があるため、公開鍵暗号を使用するのが最良の方法です。理由は、インターネット接続も敵の手にあるためです:) You <！>＃8217;あなたのソフトウェアが単にブール値を読むことを期待している場合、ホストファイルの変更はブレークワンス、ブレークブレイクエクスプロイトから離れていますインターネットから。

<！>＃8220;興味深い<！>＃8221を作成しないでください。または<！>＃8220; challinging <！>＃8221;保護。多くのクラッカーは、知的挑戦だけのためにクラックします。保護をクラックしにくくしますが、できるだけ退屈にします。

パッチを適用する場所を検索する際にバイトパターンを検索するいくつかのクラックがあります。通常は再コンパイルによって敗北しませんが、.EXEが（ASProtect、Armadilloなどによって）パックされている場合、これらの種類のクラックは最初に.EXEを解凍する必要があります。 ASProtectとして、クラッカーはSoftICEなどのアセンブリレベルデバッガーを使用してEXEを手動で解凍できますが、.EXEを自動的に解凍するツールを作成することはできません（後でバイトパッチを適用するため） ）。

Answer 6

xsl。これは非常に狭い視点であり、多くの仮定が組み込まれています。

自分の管理下にあるサーバーから何かを配信することに依存するアプリは、有効なアカウントを持っている人を把握するのにかなり良い仕事をすることができるはずだということは私には明らかです！

また、定期的な更新（別の場所にあるコードで新しくコンパイルされたアプリを意味する）により、クラックされたバージョンはすぐに陳腐化すると考えています。アプリがサーバーと通信する場合、メインの実行可能ファイルを毎週置き換えるためのセカンダリプロセスを起動するのは簡単です。

それで、はい、割れないものは何もありませんが、巧妙な固有の設計では、それが論点になります。重要な唯一の要因は、クラッカーがどれだけの時間を費やすか、そして潜在的な顧客が毎週または毎日ベースで彼らの努力の成果物を見つけようとするのにどれだけの労力を費やすかです！

もしあなたのアプリが有益で価値のある機能を提供するなら、彼らはそれに対して公正な代価を払っても構わないと思うでしょう。そうでなければ、競争力のある製品が市場に参入し、問題は解決しました。

Answer 7

過去に.NET Reactorを使用して良好な結果が得られている- http://www.eziriz.com/

この製品について気に入ったのは、かなり良い保護を得るためにコードを難読化する必要がなかったことです。