コードを難読化したことがありますか? そうする正当な理由はありますか?
13 に答える
JavaScript を難読化しました。サイズが小さくなったため、ダウンロード時間が短縮されました。さらに、コードはクライアントに渡されるため、私の会社はコードを読み取られることを望んでいませんでした。
はい、リバース エンジニアリングを困難にするためです。
もちろん、一生の仕事を確保するためです(冗談です)。
これはかなり陽気で教育的です: How to Write Unmaintanable Code .
それを「雇用保障」と呼んでいます。これは、Perl を使用する理由でもあります。難読化を別のタスクとして行う必要がないため、ジョブのセキュリティを失うことなく、生産性が向上します。
必要に応じて、「難読化によるセキュリティ」と呼んでください。
リバースエンジニアリングを難しくすることが正当な理由だとは思いません。
コードを難読化する正当な理由は、コンパイル済みのフットプリントを減らすことです。たとえば、J2ME アプリケーションはできるだけ小さくする必要があります。難読化ツール (およびオプティマイザー) を使用してアプリを実行すると、jar を数 Mb から数百 Kb に減らすことができます。
上記のもう 1 つのポイントは、ほとんどの難読化ツールは、アプリケーションのパフォーマンスを向上させるオプティマイザーでもあるということです。
これも目立たないことによるセキュリティではないでしょうか。ソース コードが公開されている場合 (javascript など)、クライアント側で実際に何が起こっているのかを理解するのが少し難しくなります。
セキュリティは常に妥協に満ちています。しかし、あいまいさによるセキュリティは、最も効果の低い方法の 1 つだと思います。
私は、すべての TV ケーブル ボックスで Java コードが難読化されると考えています。これによりハッキングが難しくなります。また、ケーブル ボックスは自宅にあるため、理論的にはハッキング可能です。
ケーブルカードは引き続き信号の暗号化を制御し、Java コードガイドや Java アプリではなくビデオソースから直接認証を取得するため、それがどれほど重要かはわかりませんが、それらはコンセプトにかなり専念しています.
ところで、難読化されたスタックからスローされた例外を追跡するのは簡単ではありません! 私はある時点で、aH が特定のビルドの「Null Pointer Exception」を意味することを覚えていました。
.NET で構築された Windows Service for Online Backup アプリケーションを作成したことを覚えています。Visual Studio または .NET Reflector などのツールを使用して、クラスとその中のソース コードを簡単に確認できました。
新しい Visual Studio Test アプリケーションを作成し、それに Windows Service 参照を追加しました。参照をダブルクリックすると、すべてのクラス、名前空間がすべて表示されます (ただし、ソース コードではありません)。クラス名を見れば、誰でもモジュールの内部動作を把握できます。私の場合、そのようなクラスの 1 つは FTPHandler で、バックアップがどこに行くのかを明確に示します。
.NET Reflector は、実際のコードを表示することで、それを超えています。プロジェクト全体をエクスポートするオプションもあるため、開発者が持っていたものと同様のすべてのクラスとソース コードを含む VS プロジェクトを取得できます。
誰かが分解するのが不可能ではないにしても、難読化することは理にかなっていると思います。また、競合他社に製品についてあまり知られたくない、大規模な顧客ベースを含む製品には意味があると思います.
Java Swing アプリをクライアントに配布する場合は、配布前に必ずクラス ファイルを難読化します。
注意しすぎることはありません.クラスファイルで適切なJava逆コンパイラ(JD Java Decompilerを使用しました- http://www.djjavadecompiler.com/)を指定したことがあり、元のコードのほぼ完全な複製が得られました。それはかなり不安だったので、それ以来、本番コードを難読化し始めました。私はクラスマスターを自分で使用しています ( http://www.zelix.com/klassmaster/ )
はい、いいえ、簡単に逆コンパイルできるツールを使ってアプリを配信したことはありません。
古い Basic および UCSD Pascal インタープリターの難読化ツールのようなものを実行しましたが、それは実行時間を最適化するという別の理由によるものでした。
私がディスク ドライバ プロジェクトのために書いたコードのいくつかを見ると、難読化されているとはどういう意味なのか疑問に思います。
((int8_t (*)( int32_t, void * )) hdd->_ctrl)( DISK_CMD_REQUEST, (void *) dr );
それとも、C でのシステム プログラミングですか? それとも、その行は別の方法で書く必要がありますか? 質問...
これは、ソースで何かを提供する必要がある場合に最も一般的に行われます(通常、共有ライブラリのないシステムなど、ビルドされている環境が原因で、特に販売者がビルド対象の正確なシステムを持っていない場合)。あなたがそれを与えている人がそれを大幅に (またはまったく) 変更または拡張できるようにしたくありません。
これは、今日よりもはるかに一般的でした。また、(廃止された?) 難読化 C コンテストにもつながりました。
合法的な (おそらく「正当」ではない) 使用法は、難読化された方法で GPL コードとリンクしているアプリの「ソース」をリリースすることです。それはソースであり、変更することができますが、非常に難しいだけです。それは、コメントなしでリリースするか、すべての空白を削除してリリースするか、(これはおそらく法的根拠を押し進めることになるでしょう) C から生成されたアセンブラー ソースをリリースする (そしておそらく手動で微調整して、そうでないと言えるようにする) よりも極端なバージョンになります。中間コードのみ)。