コード難読化の理由は？
コードを開発する人々にとっての真の利益、およびそのコードを実行するビジネス（問題のコードが実際に商用コードである場合）に関して、難読化されたコードを記述する主な理由は何ですか？ 難読化が悪よりも良かったときを説明する文書化されたケース（オンラインで利用可能な場所）がありますか？たとえば、難読化が悪意のあるサードパーティによるアクセスを有意に遅らせることが証明された有名な例はありますか？コード？車の窓を丸めるのと同じように、人々が車の窓を壊してステレオを盗むのを止めることはできません。コードを難読化すると、正直な人々が正直になります。
=========
バックグラウンド：
これは、このトピックに関する私の仮定にわざと挑戦する試みです。
私は一般にコード難読化を使用することに大いに反対していますが、何か足りないものがあるかどうか知りたいです。 JavaScriptなどの場合、縮小化によって物がより速く、すべてロードされるのに役立ちます（実際に機能的にメリットがあります）が、コードを難読化する単一の理由を思い付くことができないようです目的コード/アルゴリズムのセクションが何をするのかを発見するための障害となるは、実際にはあらゆる目的に効果的です。
オープンソースが非常に人気があるので、問題は「コードを共有するか、それを独占的に保つか」のようです。商用コードに関しては、なぜすべてを共有することができないのか、そして盗難と戦うための法律があるのは理解できます。
ところで、誰かが難読化されたコードを書いている理由が「ジョブセキュリティ」である場合、私は一貫して、意図的に難読化を使用しているプログラマーを解雇します彼らの仕事を続けるのを助けることを唯一の目的として彼ら以外はある程度のビジネス上のメリットがあることを合理的に示すことができます。それは完全に反チームであり、ばかげています。そして、彼らが素晴らしいソフトウェアを書いているので、誤った実践を通して彼らの仕事を続け、そしてそれを維持することにもっと関心がある誰かを指しています。
私はこの特定のケースについてのみ言及します。なぜなら、人々はたいてい冗談を言っていると思いますが、基本的には仕事の安全のための難読化だけが良い考えだとする答えをすべて抑止したいからです。
難読化の非常に興味深い使用例の1つは、違法コピーの起源を追跡することです。難読化が比較的安価な操作であると仮定すると、元の作成者は各クライアントに異なる難読化されたバージョンのアプリケーションを提供できます。
これは steganography の形式であり、インスピレーションを得て "traitor tracing"暗号化スキーム のバリエーションです。それが一般的かどうかはわかりません1、またはそれが良いアイデアである場合でも、実際には次のパラメータの下で適用されるのを見てきました。
- ベンダーが2つしかない競争の激しい全国市場、
- 約50の導入が市場をカバーし、
- 両方のアプリケーションの平均開発時間は数年（多かれ少なかれ）、
- アプリケーションの平均難読化時間は数時間でしたが、
- 両方のアプリケーションの寿命は、約10年と予想されていました。
理論的根拠はもちろん obcursityによるセキュリティ でしたが、ある時点で前述のスキームで進化しました2。どちらのベンダーも、お互いのバイナリコードに合法的にアクセスしており、両方からの逆コンパイルの試みが予想されていたことは明らかだと思います。難読化は、長期的にはセキュリティの面で何もしませんでした。どちらのベンダーも非常にモチベーションが高く才能のあるチームであり、非常に収益性が高くニッチな市場で働いていました。最終的に私たちの製品は似たようなものになり、他の曖昧さの少ない手段によって競争上の優位性が得られました。
（a）それは私のキャリアの非常に早い段階であり、設計の決定またはトレーススキーム（存在する場合）の結果の明確な概要が得られなかったため、および（b）私の関与の一部のため、私は本当に拡張できませんプロジェクトはNDAの下にありました。
難読化のもう1つの有効な使用例は、何らかの理由で 法的に第三者にコードを提出する義務がある の場合です。
貴社がテクノロジー企業のIP業務を行っている場合、またはソフトウェアのソースコードが関係するケースに関与している場合、クライアントのソースコードをUSPTO、裁判所または第三者に提出する義務がある場合があります。
ソースコードは企業秘密と見なされるため、ほとんどの規制機関は「50％」のルールを使用しています。提出されたソースコードは隠蔽されているため、そのまま使用することはできません。
IANAL、およびリンクは実際の作業コードではなくコードのハードコピーに関連するため、これは完全に無関係である可能性があります。
現在、JavaScriptは難読化の標準的な例であるため、一般的には考慮されない副作用が1つあり、それにより、難読化されたJavaScriptに悪意のあるコードが隠されています。縮小には明確な利点がありますが３ Javascript、私は実際の難読化には何の意味もないので嬉しいです Douglas Crockfordが同意します ：
そして最後に、コードのプライバシーの問題があります。これは失われた原因です。熱心なハッカーがプログラムを理解するのを妨げるような変化はありません。これは、すべての言語のすべてのプログラムに当てはまりますが、JavaScriptの場合はソース形式で提供されるため、JavaScriptの場合はさらに明らかに当てはまります。難読化によって提供されるプライバシーの利点は幻想です。他の人にプログラムを見せたくない場合は、サーバーのプラグを抜いてください。
「ジョブセキュリティ」の難読化については、コードレビューに合格しない動作であり、特定された場合は許容されません。最初は犯人を解雇することはしませんが、少なくとも犯罪者を繰り返すことは間違いなく良いスパンキングに値します。
結論として、難読化はあいまいさによるセキュリティの典型的な例です。明らかなメリットは抑止力としてであり、それ以上のものではありません。クリエイティブなユースケースがあるかもしれません4 私にはわかりませんが、一般的にはメリットは最小限で、せいぜい最小限です。
1 これを書いた後、私は this answer を見つけました。これは基本的に同じスキームを説明しているので、私が思ったのはより一般的かもしれません。
2 ステガノグラフィーはまだあいまいなためセキュリティです。
３ ミニフィケーション〜意図的に不明瞭にしないで、空白を削除してトークンを短くする。
4 国際難読化Cコードコンテスト は重要ですか？
コード難読化のケースは、サードパーティがコードの機能/方法を判断する際の基準を引き上げることです。
ただし、これは[〜＃〜]しない[〜＃〜]は、開発者が難読化されたコードを書く必要があることを意味します。
これは私があなたの質問から欠落していると思うビットです：コードの難読化（ちょうどJavaScriptの縮小化のように）は開発者が手動で行う必要はありません-すべきではありません-。同様に、これもバージョン管理のコアソースファイルとして保存しないでください。
コード難読化は、本番ビルドへのコンパイル中の後処理ステップとして発生するはずです。これを行うサードパーティ製品もたくさんありますので、社内でこれを行う理由はほとんどありません。
例： Dotfuscator
IEEEは コード難読化の有効性 に関する論文を発表しています。
結果は、識別子の名前を変更すると攻撃の効率が大幅に低下することを示しています攻撃を完了するために必要な時間を少なくとも2倍にする（最悪のシナリオでも）最高の攻撃者に対して）。さらに、難読化は、初心者と熟練した攻撃者の間のギャップを減らし、後者の効率を下げます。本質的に壊れにくいもの。
鉱山を強調します。
MMORPGの開発に参加しています。これには、サーバーロジックとクライアントロジックが含まれます。プロジェクトの何年にもわたる開発を通じて、クライアントとサーバー間のインターフェイスを検討するときは常に、ハッキングされたという前提の下で、クライアントは常にサーバーによって処理される必要があるという規則がありました。言い換えると、サーバーは、サーバーの障害やクライアントのチートを引き起こすようなクライアントからの応答がないように書かれていなければなりませんでした。それでも、ハッカーがシステムの穴を必然的に見つけ、不正を行うためにそれらを悪用することが最初から知られていました。そしてしばらくして、彼らはそうしました。
もちろん、クライアントを大きな世界に送る前に、それを難読化するようにしました。難読化によって次の影響があったと考えられます。
- 専門家ではないハッカーが試みることを阻止しました。
- 専門家によるハッカーのハッキングを遅らせました。
- 専門のハッカーによるハッキングの数を減らしました。
- それはハックの効果を制限しました。
- 最も重要なこと：ハッカーは、ハッキングを実行する前に、ハッキングされたクライアントを使用してサーバーに対してより多くのテストを実行し、サーバーログで不規則なアクティビティを探すことでハッカーを発見する可能性を高めました。
発見されたハッカーのゲームアカウントは払い戻しなしで終了されたため、ハッキングビジネスのコストが高くなり、魅力がなくなりました。
したがって、上記のすべてが原因で、難読化がゲーム全体にプラスの効果をもたらしたと私は考えています。ひいては、ハッキングされる可能性のあるすべてのソフトウェアに難読化が全体的にプラスの効果をもたらす可能性があります。 （たとえば、コピー防止対策を含むソフトウェア。）
難読化によるメンテナンスへの影響はほとんどありませんでした。経験の浅いプログラマーが識別子の名前を想定している場所がいくつかありました（リフレクションを使用していた）が、それらが整理されると、すべてが問題なく完了しました。難読化ステップは、ゲームの製品版の全体的なビルドステップの一部になりました。そのため、ほとんどの開発者は、それについて心配したり、それと関係したりする必要はありませんでした。ゲームのログを表示するツールはすでにあったため、難読化ツールによって生成された関連付けテーブル（難読化された識別子を適切な識別子にマッピングする）を使用するようにツールを変更し、ログをその場で変換して、フィールドから収集されたログに基づいて事後調査を行っている間、難読化された識別子を確認する必要さえありました。
難読化されたコードを読んで理解する（そして明らかに書く）ことは、興味深い精神的な挑戦になる可能性があります。それはおそらくあなたが求めていたものの範囲外ですが、 [〜＃〜] ioccc [〜＃〜] のような例は、恐怖だけでなく娯楽の源になるかもしれません。