Protector4J はどのように機能しますか?

現在のJavaコード保護ソリューションの問題点

Protector4J の仕組みを理解する前に、まず他の Java コード保護ソリューションに存在する問題について学びましょう。

コードの難読化

JVMバイトコードは高度なセマンティクスを持つため、解析と読み取りが非常に容易です。動的デバッグによって実行ロジックを容易に解析できるため、難読化は信頼できる保護ソリューションとは言えません。

詳細については、次の記事を参照してください。 https://protector4j.com/articles/the-issues-of-code-obfuscation/

クラスファイルの暗号化

JVMアタッチメントメカニズムの存在により、通常のJREからデタッチされていないいわゆる暗号化コードは、アタッチメントツールを介して簡単に取得できます。したがって、これは最も効果のない保護ソリューションです。

詳細については、次の記事を参照してください。 https://protector4j.com/articles/the-issues-of-class-encryption/

VMP保護

仮想化保護は最も安全なコード保護方法ですが、パフォーマンスに深刻な影響を与えるため、プログラム内の重要なコードにのみ適用できます。他のコードは依然として露出のリスクが残ります。コードの他の部分を標的とすることで、クラッカーは仮想化コードの機能情報を取得することができます。

具体的な詳細については記事を参照してください。 https://protector4j.com/articles/the-issues-of-vm-protection/

AOTコンパイル

AOTコンパイルの設定とコンパイルは非常に難しく、コンパイルに失敗する確率も高くなります。たとえコンパイルに成功したとしても、コードロジックはバイトコード表現からマシンコード表現に変換されるだけで、特別な保護は施されずにそのまま存在します。コンパイルと実行の仕組みを理解できれば、可読なコードをリバースエンジニアリングすることも可能です。

詳細については、次の記事を参照してください。 https://protector4j.com/articles/the-issues-of-aot-protection/

Protector4J はどのように機能しますか?

我々はプライベートな圧縮パッケージフォーマットを定義しました: JARX

Javaコードを保護するため、JARXと呼ばれる独自の圧縮ドキュメント形式を作成し、JVMランタイムに統合しました。Protector4Jで処理されたJARファイルは、JARX形式に変換されます。

JVMに大幅なカスタマイズと変更を加えました

JVMを徹底的に研究し、徹底的なカスタマイズと改良を行いました。追加メカニズムをすべて削除し、バイナリセキュリティレベルで大幅な強化と最適化を実施しました。これにより、クラッカーが既存の手法を用いてクラス情報をエクスポートするのを阻止できます。Protector4Jによって保護された暗号化アプリケーションは、現状の強度で高いセキュリティレベルを備えていると考えています。しかし、クラッキングとアンチクラッキングの戦いは常に進化を続けています。私たちは、アプリケーションのセキュリティを継続的に強化するために、暗号化と保護ソリューションの改良を継続的に進めていきます。