私はただいじっていました。dex2jar http://code.google.com/p/dex2jar/と Java Decompiler JD-GUI http://java.decompiler.free.fr/?q=jdguiをダウンロードしました
私は独自のapkファイル（署名済み、封印済み、Google Play上）を取得し、dex2jarを使用してそれをjarリポジトリにしました。
コマンド ライン (Windows ユーザーは .bat、それ以外は .sh を使用):
d2j-dex2jar.bat -f MyAwesomeApp.apk
出力を JD-GUI にドラッグ アンド ドロップすると、すべてのクラス ファイル、元のコードが再び表示されました。ちょっとビックリしました。私の Java/Android コードは公開されていますか? APK を簡単に逆コンパイルして再生成できる場合、ProGuard はどのように APK を保護していますか? 全然歪んでないように見える…
前もって感謝します。
難読化ツールは通常、クラス、メソッド、フィールドの名前を意味のない名前に変更するだけです。したがって、「ScoreCalculator.computeScore(Player p, Match m)」がある場合、「A.zk(F f, R r)」になります。これは、JavaScript でソース長を短縮することを除いて、Uglify または Closure コンパイラが JavaScript に対して行うことと似ています。
とにかくメソッドが何をするかを理解することは可能ですが、それは難しいだけです。
同様に、Java は遅延バインディングを (DLL または SO ファイルとして) 使用します。そのため、コードの外に出る呼び出し (java.util、java.lang などのパッケージ) は難読化できません。また、コードが外部からの呼び出しを受信する必要がある場合 (典型的な例では、ボタンにリスナーを登録する)、そのコードを難読化することはできません。DLL についても同じことが起こります。ここでは、DLL の外部から呼び出す必要があるメソッドの名前と、他の DLL への呼び出しを明確に確認できます。
ただし、特定のソース コードとコンパイルされたコードとの間のマッピングは、必ずしも 1 対 1 であるとは限りません。古い C コンパイラは、特定のソース ディレクティブに対して同じ op コードを生成していたため、逆コンパイラは非常に効果的でした。その後、C コンパイラは結果の op コードに多くの最適化を追加し、これらの最適化により逆コンパイラはほとんど効果がなくなりました[1]。
Java はコンパイル時に (多くの) 最適化を実装しませんでした。これは、異なるプラットフォーム (異なる Android デバイスを含む) で実行するために、Java は、実行中のデバイスのアーキテクチャとハードウェア プロパティに基づいて、後で実行時に深刻な最適化を適用することを決定したためです。 (これが「HotSpot」の主な内容です[2] )。
優れた難読化ツールは、通常、バイトコード命令を並べ替えたり、役に立たないものを挿入したり、事前に最適化を適用して、逆コンパイラがソース コードを簡単に取得できない (または可能性が低くなる) ようにします。
この手法は、バイトコードを読める人にとっては役に立ちません。アセンブラー コードを読める人が C 難読化を行っても役に立たないからです。
多くのクラッキング ソフトウェアが示すように、リバース エンジニアリングは常に可能です。C 言語やその他の言語、ファームウェア (iPhone ファームウェアについて考えてください) であっても、コードが実行されているクライアントは常に信頼されておらず、常に改ざんされる可能性があります。
非常にミッション クリティカルなコード、つまり誰かに盗まれる可能性のある高額なコードがある場合は、サーバー側で実行するか、何らかの方法でサーバー側で検証することをお勧めします。