セットアップを展開すると、アセンブリも展開され、ユーザーが Program Files からアセンブリを取得し、他のプロジェクトへの参照を追加したり、それに基づいて新しいプロジェクトを作成したりする可能性があるため、アセンブリを保護するにはどうすればよいですか? 解決策や助けをいただければ幸いです。
6 に答える
アセンブリ内部のすべてのメンバーを作成し、InternalsVisibleToAttributeによって他のメンバーのみが使用できるようにすることができます。しかし、誰かが十分に粘り強い場合、その使用を止める方法はありません。
アセンブリのコードを難読化して、それを使用するタスクをより困難にすることはできますが、ユーザーがアセンブリを選択して使用するのを 100% 防止するためにできることはあまりありません。できることは、アセンブリをユーザーのコンピューターに展開するのではなく、Web サービスを介して機能を提供することです。
それを完全に防ぐことはできません。ただし、公開されたクラスとメソッドに適切な名前がないように、アセンブリを難読化することができます。
そのような難読化ツールの 1 つがオープンソースであり、obfuscar と呼ばれます。継続的なプロジェクトは、このリンクの下にあります。
簡単な方法はありません。難しくすることしかできません。あなたのアルゴリズムが非常にユニークで貴重なものであり[1]、第三者が使用できないようにする (またはのぞき見ることができない) 必要がある場合、唯一の選択肢は、ロジックを離れた場所 (サーバーの背後) に配置し、プログラムを保持することです。あれを呼べ。
[1] 私の謙虚な経験では、決してそうではありません。
明らかに安全ではありませんが、復号化キーをどこかに保存する必要がありますが、DLL をディスク上で暗号化し、それらをロードしてメモリ内で復号化することは問題なく機能します。
AppDomain.CurrentDomain.AssemblyResolve をカスタム ハンドラーでフックすると、透過的に行うこともできます。アセンブリが特定の DLL を読み込もうとすると失敗し、ハンドラーが起動して、暗号化された DLL からアセンブリを読み込みます。
私はまだこのアプローチで問題を見つけていません。
また、完成した DLL を自分のプロジェクトで使用する人だけが心配な場合は、コードにいくつかのスタック チェックを追加し、実行中のアセンブリを解決してハッシュ チェックを実行することもできます。ただし、これらの対策はいずれも DLL から簡単に編集できます。
ILmerge を使用してアセンブリを実行可能ファイルにマージし、難読化を使用してパッケージ全体を保護できます (.NET 実行可能ファイルは、リンク先のアセンブリとして扱うことができます)。