誰かが自分の商用製品に商用/無料のJava難読化ツールを使用しているのではないかと思います。リリースのantビルドステップで実際に難解なステップがあったプロジェクトは1つしか知りません。
難読化していますか？もしそうなら、なぜあなたは難読化するのですか？
それは本当にコードを保護する方法ですか、それとも開発者/管理者にとってより良い感じですか？
編集：わかりました、私のポイントについて正確に言えば：あなたはあなたのIP（あなたのアルゴリズム、あなたがあなたの製品に入れた仕事）を保護するために難読化していますか？私はセキュリティ上の理由で難読化するつもりはありません、それは正しくないと感じています。つまり、競合他社からアプリケーションコードを保護することだけを話しているのです。
@staffanには良い点があります：
コードフローの連鎖を避ける理由は、これらの変更の一部により、JVMがコードを効率的に最適化できなくなるためです。実際には、アプリケーションのパフォーマンスが低下します。
難読化する場合は、コードフローを変更したり、例外ブロックなどを追加したりしてコードを変更する難読化ツールに近づかないようにして、コードを分解しにくくします。コードを読めなくするには、通常、メソッド、フィールド、クラスのすべての名前を変更するだけで十分です。
コードフローの変更を避ける理由は、これらの変更の一部により、JVMがコードを効率的に最適化できなくなるためです。実際には、アプリケーションのパフォーマンスが低下します。
難読化の古い (古典的な) 方法は、その関連性を徐々に失っていると思います。ほとんどの場合、従来の難読化ツールはスタック トレースを破壊するため (クライアントのサポートには適していません)
現在、いくつかのアルゴリズムを保護するのではなく、機密データを保護することが主なポイントです: API ログイン/パスワード/キー、ライセンスを担当するコード (海賊行為、特に西ヨーロッパ、ロシア、アジア、IMHO)、広告アカウント ID など.
興味深い事実: この機密データはすべて文字列に含まれています。実際、文字列はアプリケーションのロジックの約 50 ～ 80% を占めています。難読化の未来は「文字列暗号化ツール」だと思います。
しかし現在、「文字列暗号化」機能は、 Allatori、Zelix KlassMaster、Smokescreen、Stringer Java Obfuscation Toolkit、DashOなどの商用の難読化ツールでのみ使用できます。
NB 私は Licel LLC の CEO です。Stringer Java Obfuscator の開発者。
私はJavaME開発にproguardを使用しています。jarファイルを小さくするのに非常に優れているだけでなく（モバイルに不可欠）、アンテナなどのIDEに適さない前処理ツールを使用せずにデバイス固有のコードを実行するためのより良い方法として役立ちます。
例えば
public void doSomething()
{
/* Generated config class containing static finals: */
if (Configuration.ISMOTOROLA)
{
System.out.println("This is a motorola phone");
}
else
{
System.out.println("This is not a motorola phone");
}
}
これはコンパイルされ、難読化され、クラスファイルは次のように記述されたようになります。
public void doSomething()
{
System.out.println("This is a motorola phone");
}
したがって、最終的な実行可能クラスファイルをまとめることなく、JVM/ライブラリ実装の製造元のバグを回避するためのコードのバリアントを使用できます。
一部の商用難読化ツールは、場合によってはクラスファイルをマージすることもできると思います。クラスが多いほど、zip（jar）ファイルのオーバーヘッドのサイズが大きくなるため、これは便利です。
私はProGuardを使用しており、強くお勧めします。難読化はコードを偶然の攻撃者から保護しますが、その主な利点は、未使用のクラスとメソッドを削除し、すべての識別子を1文字または2文字に短縮する効果を最小限に抑えることです。
今年、さまざまな Java 難読化ツールを試してみたところ、他よりも数マイル先を行っているJBCOが見つかりました。残念ながら、設定が少し面倒で、GUI もありませんが、生成される難読化のレベルという点では比類のないものです。単純なループをフィードしてみます。ロードしようとして逆コンパイラがクラッシュしない場合は、次のように表示されます。
if(i < ll1) goto _L6; else goto _L5
_L5:
char ac[] = run(stop(lI1l));
l7 = (long)ac.length << 32 & 0xffffffff00000000L ^ l7 & 0xffffffffL;
if((int)((l7 & 0xffffffff00000000L) >> 32) != $5$)
{
l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL;
} else
{
for(l3 = (long)III & 0xffffffffL ^ l3 & 0xffffffff00000000L; (int)(l3 & 0xffffffffL) < ll1; l3 = (long)(S$$ + (int)(l3 & 0xffffffffL)) ^ l3 & 0xffffffff00000000L)
{
for(int j = III; j < ll1; j++)
{
l2 = (long)actionevent[j][(int)(l3 & 0xffffffffL)] & 65535L ^ l2 & 0xffffffffffff0000L;
l6 = (long)(j << -351) & 0xffffffffL ^ l6 & 0xffffffff00000000L;
l1 = (long)((int)(l6 & 0xffffffffL) + j) & 0xffffffffL ^ l1 & 0xffffffff00000000L;
l = (long)((int)(l1 & 0xffffffffL) + (int)(l3 & 0xffffffffL)) << 16 & 0xffffffff0000L ^ l & 0xffff00000000ffffL;
l = (long)ac[(int)((l & 0xffffffff0000L) >> 16)] & 65535L ^ l & 0xffffffffffff0000L;
if((char)(int)(l2 & 65535L) != (char)(int)(l & 65535L))
{
l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL;
}
}
}
}
Java に goto があることを知らなかったのですか? まあ、JVMはそれらをサポートしています=）
ほとんどの場合、難読化は無意味だと思います。完全なソースコードを使用しても、一般的に、一体の意図が何であるかを理解するのは十分に困難です（コメントがなく、ローカル変数に意味のある名前がないと仮定すると、これはreの場合です。 -バイトコードからソースを生成する）。難読化はケーキを飾るだけです。
開発者、特にそのマネージャーは、誰かがソースコードを見るリスクを大幅に誇張する傾向があると思います。優れた逆コンパイラーは見栄えの良いソースコードを生成できますが、それを使用するのは簡単ではなく、関連するコスト（法的リスクは言うまでもなく）は、このアプローチがほとんど役に立たないほど高くなります。クローズドソースベンダーの製品の問題をデバッグするために逆コンパイルしただけです（DB抽象化レイヤーのデッドロック、うーん）。バイトコードは実際には難読化されていたと思いますが、それでも根本的な問題が見つかりました。それは実際の設計上の問題でした。
それは本当にあなたのJavaコードが何のためにあるのか、それがどのように配布されるのか、そしてあなたのクライアントが誰であるかにかかっていると思います。特に優れたものは見つかったことがなく、価値があるよりも厄介になる傾向があるため、何も難読化することはありません。誰かが私たちのJARファイルにアクセスでき、その中を嗅ぎ回ることができる知識を持っている場合、私たちのソースコードをはぎ取るよりもはるかに心配なことがあります。