コードの難読化のケース？

コードを開発する人々にとっての実際の利益と、そのコードを実行するビジネスの観点から、難読化されたコードを書く主な理由は何ですか（問題のコードが実際に商用コードである場合）？難読化が悪い場合よりも良い場合を説明する文書化されたケース（ある場所でオンラインで入手可能）はありますか？たとえば、難読化が悪意のある第三者によるコードの取得を有意に遅らせることが証明されている有名な例はありますか？あなたの車の窓を丸めても人々がそれらを壊してステレオを盗むのを止めないように、コードを難読化することは正直な人々を正直に保つだけです。

=========

バックグラウンド：

これは、このトピックに関する私の仮定に意図的に挑戦する試みです。

私は一般的にコードの難読化を使用することに反対していますが、何かが足りない場合は興味があります。JavaScriptのような場合、ミニフィケーションが物事をより速く、すべてロードするのに役立つ理由がわかります（そこには実際の機能上の利点があります）が、コードの難読化が障害となる目的で単一の理由を考え出すことはできないようですコード/アルゴリズムのセクションが何をするかを発見することは、実際にはどんな目的にも効果的です。

オープンソースが非常に人気があるので、質問は「コードを共有するのか、それともプロプライエタリのままにするのか？」商用コードに関しては、なぜすべてを共有できないのか、そして盗難と戦うための法律があなたの側にあるのは理解できます。

ところで、誰かが難読化されたコードを書いている理由は、「雇用保障」であるならば、私はすべてのプログラマを解雇でしょうが一貫してあることが判明し、意図的に難読化を使用して、自分の仕事を維持するために助ける唯一の目的と、彼らは合理的に、それはいくつかを持っていたことを示すことができない限り、ビジネス上の利益。それは非常に完全に反チーム的であり、ばかげており、見当違いのプラクティスを通じて仕事を続け、素晴らしいソフトウェアを書いているのでそれを維持することにもっと関心がある人を指します。

人々がふつう冗談を言っていることに気づいている間、私はこの特定のケースに言及するだけです。

難読化の非常に興味深い使用例の1つは、違法コピーの起源を追跡することです。難読化は比較的安価な操作であると仮定すると、元の作成者は各クライアントに異なる難読化されたバージョンのアプリケーションを提供できます。違法コピーが見つかった場合、作成者は提供されたバージョンと比較して著作権侵害の原因を追跡できます。

それはステガノグラフィの一種であり、「裏切り者の追跡」暗号化スキームにインスパイアされたバリエーションです。それが一般的であるかどうかはわかりません¹、またはそれが良いアイデアであっても、私はそれが次のパラメータの下で実際に適用されるのを見ました：

• ベンダーが2つしかない非常に競争の激しい全国市場、
• 約50の展開が市場をカバーし、
• 両方のアプリケーションの平均開発時間は数年（多かれ少なかれ）でした。
• アプリケーションの平均難読化時間は数時間でしたが、
• 両方のアプリケーションの寿命は約10年と予想されていました。

理論的根拠は、最初はあいまいさによるセキュリティでしたが、前述のスキームのある時点で進化しました²。両方のベンダーが合法的に互いのバイナリコードにアクセスできたため、両方からの逆コンパイルの試みが予想されたことは明らかだと思います。長い目で見れば、難読化はセキュリティの面では何もしませんでした。両方のベンダーは非常に意欲的で才能のあるチームを持っていて、非常に収益性の高いニッチ市場で働いていましたが、最終的に私たちの製品はよりよく似ており、他の不明瞭な手段によって競争上の優位性が得られました。

（a）私のキャリアの非常に早い時期であり、設計決定またはトレーススキームの結果（ある場合）の明確な概要が得られなかったため、および（b）私の関与の一部このプロジェクトはNDAの下にありました。

難読化のもう1つの有効な使用例は、何らかの形でコードを第三者に送信する法的義務がある場合です。

あなたの会社がテクノロジー企業のために知的財産権の仕事をしている場合、またはソフトウェアのソースコードが関係する場合は、クライアントのソースコードをUSPTO、裁判所または第三者に提出する義務があります。

ソースコードは企業秘密と見なされるため、ほとんどの規制当局は「50％」ルールを使用しています。送信されたソースコードは隠されているため、そのままでは使用できません。

IANAL、およびリンクは実際の作業コードよりもコードのハードコピーにより関連しているため、これは完全に無関係です。

現在、Javascriptは難読化の標準的な例であるため、一般に考慮されていない副作用が1つあり、難読化されたJavascriptに悪意のあるコードが隠れています。³ Javascript を縮小することには明確な利点がありますが、実際の難読化には意味がありません。DouglasCrockfordが同意してくれてうれしいです：

そして最後に、コードのプライバシーの問題があります。これは失われた原因です。熱心なハッカーがプログラムを理解するのを妨げるような変換はありません。これは、すべての言語のすべてのプログラムに当てはまります。JavaScriptがソース形式で提供されるため、JavaScriptの方が明らかに当てはまります。難読化によって提供されるプライバシーの利点は幻想です。他の人にプログラムを見せたくない場合は、サーバーのプラグを抜いてください。

「ジョブセキュリティ」の難読化に関しては、これはコードレビューに合格するべきではない動作であり、特定された場合、それは許容されるべきではありません。最初は犯人を解雇することはしませんでしたが、少なくとも繰り返し犯人は間違いなく良いスパンキングに値します。

結論として、難読化は、あいまいさによるセキュリティの典型的な例であり、明らかなメリットは抑止力としてのみであり、それ以上のものではありません。クリエイティブなユースケース⁴があるかもしれませんが、一般的にはせいぜい最小限の利点しかありません。

_{¹これを書いた後、私は基本的に同じスキームを説明するこの答えを見つけたので、私が思ったよりも一般的かもしれません。
²ステガノグラフィーは、あいまいさによる安全性を保っていますが。
³ミニフィケーション〜空白を削除してトークンを短縮します。意図的に不明瞭にすることはありません。
^4はい国際難読Cコードコンテストの数を？}

コードの難読化のケースは、コードが何を/どのように機能しているかを判断するためのサードパーティの水準を上げることです。

ただし、それは開発者が難読化されたコードを記述する必要があるという意味ではありません。

ご覧のとおり、これはあなたの質問に欠けていると思うビットです：コードの難読化（JavaScriptの縮小と同様）は開発者が手動で行う必要はなく、そうすべきではありません。同様に、これもバージョン管理のコアソースファイルとして保存しないでください。

コードの難読化は、実動ビルドへのコンパイル中のポスト処理ステップとして発生するはずです。これを行うサードパーティ製品も多数あるため、社内でこれを行う理由はほとんどありません。

例：Dotfuscator

IEEEには、コードの難読化の有効性に関する論文があります

結果は、識別子の名前を変更すると攻撃の効率が大幅に低下し、攻撃が成功するのに必要な時間が少なくとも2倍になることを示しています（最悪のシナリオ、つまり最高の攻撃者であっても）。さらに、難読化により、初心者と熟練した攻撃者との間のギャップが減少し、後者の効率が低下し、攻撃しやすいシステムが本質的に破壊されにくいシステムに似たものになります。

強調鉱山。

MMORPGの開発に参加しました。これには、サーバーロジックとクライアントロジックが関係していました。プロジェクトの長年にわたる開発を通して、クライアントとサーバー間のインターフェイスを検討するときは常に、クライアントはハッキングされたという仮定の下でサーバーによって常に扱われるべきであるというルールがありました。つまり、サーバーは、サーバーに障害を引き起こしたり、クライアントがチートを許可したりするクライアントからの応答がないように作成する必要がありました。それでも、最初からハッカーがシステムに穴を見つけて、それを悪用して悪用することがわかっていました。そしてしばらくして、彼らはそうしました。

もちろん、クライアントを大きな世界に出荷する前に、クライアントを難読化することを確認しました。難読化には次の効果があると考えられます。

1. それは、専門家でないハッカーが試みることさえも阻止しました。
2. 専門のハッカーがハッキングを達成するのを遅らせました。
3. 専門のハッカーが達成するハッキングの数を減らしました。
4. ハッキングの有効性が制限されていました。
5. 最も重要なことは、ハッカーがハッキングを行う前に、ハッカーがサーバーに対してより多くのテストを実行するようにしたため、サーバーログで不規則なアクティビティを探すことでそれらを発見する機会が増えました。

発見されたハッカーのゲームアカウントは払い戻しなしで終了したため、ハッキングビジネスのコストが高くなり、魅力的ではなくなりました。

したがって、上記のすべての理由により、難読化はゲーム全体にプラスの効果をもたらし、ひいては難読化はハッキングされる可能性のあるソフトウェアの一部に全体的にプラスの効果をもたらす可能性があると思います。（たとえば、コピー防止対策を含むソフトウェア。）

難読化がメンテナンスに及ぼす影響はほとんどありませんでした。経験の浅いプログラマーが識別子の名前について推測している場所がいくつかありましたが（それらはリフレクションを使用していました）、一度それらが整理されるとすべてがうまくいきました。難読化の手順は、ゲームの製品版の全体的なビルド手順の一部になったため、ほとんどの開発者はそれを心配したり、関係したりする必要はありませんでした。すでにゲームのログを表示するツールがあったので、ツールを修正して、難読化ツールによって生成された関連付けテーブル（難読化された識別子を適切な識別子にマッピングする）を使用して、その場でログを翻訳するようにしました。現場から収集されたログに基づいて事後検査を行う際に、難読化された識別子を見なければなりませんでした。

難読化されたコードを読んで理解する（そして明らかに書く）ことは、興味深い精神的な挑戦になる可能性があります。それはおそらくあなたが求めていたものの範囲外になりますが、IOCCCのような例は、恐怖だけでなく娯楽の源かもしれません。