2

私たちが知っているように、.class を .java ファイルに変換できる Java 逆コンパイラ ツールはたくさんあります。

したがって、逆コンパイラから .java ファイルを保護する必要があります。私はこれが大きなトピックであることを知っています、そしておそらく終わりはありません.

通常、難読化ツールとカスタマイズされたクラスローダーの 2 つの方法があります。

これら 2 つの方法を組み合わせた成熟したソリューションまたはオープン ソース フレームワークはありますか?

別の側面は、jar を exe ファイルにパッケージ化する exe4j に関連しており、jar ファイルやクラス ファイルではなく exe ファイルが表示されるため、Java コードを保護できるようです。しかし、実行すると、すべての jar ファイルが一時ディレクトリに分解されます。つまり、逆コンパイラ用のクラス ファイルを簡単に取得できます。exe4j の側面から Java コードを保護するための考慮事項はありますか?

コメントと提案をありがとう。

更新中

提案や経験の共有に感謝します。それは私にとって役に立ちます。結論として、難読化ツールやカスタマイズされたクラスローダーを暗号化することはあきらめます。最終的に、巧妙なハッカーの前に Java コードが公開される可能性があるからです。

C 言語の「#ifdef」などのトリックを使用して、コンパイラ時にいくつかのコア コードを削除します。Java では、静的および最終のブール型クラス変数を使用して同じ作業を行うことができます。コンパイルされたクラス ファイルには、必要に応じて保護された Java コードは含まれません。

4

9 に答える 9

18
  1. ProGardやYgardなどの難読化ツールを使用できますが、文字列を復号化し、クラス、フィールド、メソッドの名前を変更するのはそれほど複雑ではありません。
  2. クラスを秘密鍵で暗号化し、カスタムクラスローダーを使用して公開鍵でクラスを復号化してからメモリにロードできますが、ロードされたすべてのクラスをディスクに保存するようにクラスローダーを変更するのはそれほど複雑ではありません。
  3. クラッシュデコンパイラを試すことができます。JADは最高の逆コンパイラの1つですが、定数プールに破損したエントリを追加すると、JADを搭載したすべての製品がクラッシュします。ただし、一部の逆コンパイラはまだ機能しています。

ソフトウェアを保護する唯一の方法は、SaaS/PaaSにデプロイすることです。

ただし、頭を悩ませないでください。ほとんどの人は、技術的な問題があり、ドキュメントが不十分または存在しないため、逆コンパイラを使用します。優れたドキュメントを作成し、堅実なEULAを使用することがより優れたソリューションです。

于 2009-12-10T19:55:53.193 に答える
12

逆コンパイラや悪意のあるユーザーからクラス ファイルを保護することはできません。ただし、逆コンパイラの出力は有効な Java ではない場合があります。

最善の方法は、API (顧客が使用できると仮定) とアプリケーションを非常によく文書化することです。また、サポート担当者が API とアプリケーションの問題を解決できるようにします。そうすれば、顧客は逆コンパイラを使用して、正しく動作しない理由を調べようとする理由がなくなります。

于 2009-12-10T06:51:20.410 に答える
10

サービスとしてのソフトウェア。

于 2009-12-10T06:40:48.263 に答える
6

特に効果的な唯一の方法は、プログラムをある種のWebサービスとして提供することです。これにより、コンパイルされたコードがエンドユーザーのマシンで利用できるようになることはありません。

次に広く使用されている解決策は、プログラムをひどくして、誰もそれを使用したり、そもそもリバースエンジニアリングに時間を費やしたりしたくないようにすることです。ただし、これが発生した場合、通常は偶発的であると思われます。

于 2009-12-10T07:12:01.400 に答える
1

オープンソースのプロジェクトプロガードを試すことができます

于 2009-12-10T07:08:41.047 に答える
1

実際、Java だけでなく、Silverlight や Flash も同じ問題を抱えています。パッケージをダウンロードした人は誰でも、解凍してから逆コンパイルして、コードをリバース エンジニアリングできます。

SaaS が最適なソリューションになることに同意します。Web サービスですべての基本的なロジックを処理し、データを提供することで、エンド クライアントがデータを消費するための比較的安全で分離されたレイヤーを確立できます。

于 2009-12-10T07:23:15.187 に答える
1

私のアドバイスは、これについて本当に真剣に考えているのであれば、法的拘束力のある秘密保持契約に署名した人々にのみデモ ソフトウェアをリリースするべきだということです。そして、彼らが契約に違反した場合、法廷に行く準備をしてください。

必ず、デモ アプリケーションなども難読化してください。ただし、これによって、ハッカーがアプリケーションの「秘密のソース」を発見するのを阻止できるとは思わないでください。理論上も実際上も、これを防ぐことはできません。ソフトウェアの収益化に有料ライセンス モデルを使用している場合、著作権侵害は避けられません。

(実際には、理論的には可能ですが、 TPMのような完全に安全なプラットフォームでのみ可能です。そして、それはあなたのためのオプションではありません.私を信じてください.)

于 2009-12-10T09:45:39.430 に答える
1

すべてがハッキング可能です。コードを保護する絶望的な試みに労力を費やすのではなく、しっかりとした EULA を用意して、そこに努力を注ぐだけです。

于 2009-12-10T12:37:44.423 に答える
0

クラス ファイルを暗号化し、カスタマイズされたクラスローダーを使用してクラス ファイルをロードするのはどうでしょうか。

于 2009-12-10T12:33:11.530 に答える