コードの難読化は、測定可能なセキュリティ上の利点をもたらしますか？
私は常に、難読化は本質的に役に立たないという信念を堅持してきました。難読化されたコードは読むことが不可能ではなく、読むのが難しいだけです。私は十分に熟練した攻撃者が難読化されたコードをより読みやすい状態に戻すことができると信じていました。
ただし、 OWASPが推奨 モバイルクライアントの難読化の使用。これにより、難読化の信頼性が私が与えたものよりも高いかどうか疑問に思います。
したがって、私の質問：難読化は測定可能なセキュリティ上の利点をもたらしますか？具体的には、追加のコスト、複雑さ、パフォーマンスの低下を上回るメリットがあります。
注：「難読化」とは、リバースエンジニアリングを防止するために行われた意図的な手順のことです。コンパイラの最適化は、アセンブリを読みにくくしますが、リバースエンジニアリングを防ぐためではなく、パフォーマンスを向上させるために行われます。
コード難読化には2つの利点があります。
- 攻撃者プールの浅い端を取り除きます。コードを理解するのに苦労しているスクリプトキディは、別の場所に行きます。
- 熟練した攻撃者に必要な労力が増加します。それらがどれほど熟練しているかに関係なく、難読化は解読よりも安価であり、結果は一般に元のものよりも理解しづらくなります（変数名は、たとえば、元の名前が説明的だった場合など、汎用のままです）。
@SteveSetherは彼のコメントで二重に正しい-実際のmeasurementsを見つけることはほとんど不可能であり、多くのコードベースはセキュリティ上の理由ではなく独自の理由*によって難読化されています。
ただし、セキュリティ上の理由と独自の理由により、コードの難読化の価値は非対称の品質に結び付けられています。難読化を解除するよりも難読化する方が安上がりです。
*「独自の理由」とは、「市場における競争上の優位性を維持するために、コードとアルゴリズムをよりプライベートに保つ、または再現するのをより困難にしたい」という意味です。企業と個人の両方がこの傾向になりやすい。
インターネットから受け取ることができるすべてのもの（メール、ftp、web、dnsなど）の難読化されたコード（主にvirusesおよびrootkitsにある）を見ている限り、リクエスト、ログ、ファイル転送）、deobfuscatingに含まれる人間の時間サーバーアドレス、admin idなどの重要な情報を見つけるのに十分なコードボットネットのハッシュされたパスワード、またはウイルスのセンシティブストリングまたはライブラリコールは、主に分単位でカウントされます。
したがって、奇妙なコードからの保護という点では、これは大きな仕事ではありません（些細ではないにしても）。
一方、この種のコードからeditable sourcesをビルドすると、時間がかかる可能性があります（コードが大きい場合は、日、週、またはそれ以上に数えられます。とにかく、難読化解除プロセスが進むにつれて、 、光が来ているときのように、より効率的で迅速です）。
OWASPの推奨事項について、私は同意します。難読化は人的資源を意味するため、一部のコストを表し、著作権侵害を少なくします魅力的。
measurablilityについてsecurity benefit...申し訳ありませんが、できません！ whoに応じて、コードをハッキングすることで興味を持つ可能性があります--- [の一部コードと- 理由。
全体として、私自身の推奨事項は次のとおりです。obfuscationを使用することは本質的に悪い考えではありませんが、大きなセキュリティの改善とは見なされません。
より明確にするために、コードを難読化して秘密鍵/関数を非表示にすることを検討しないでください。これにより、難読化されていない場合よりも安全になります。
難読化のもう1つのポイントは、攻撃者がリバースエンジニアリングアクティビティを拒否することを困難にすることです。
「Hello foobar」文字列を送信するクライアントを許可するサーバーがあり、誰かがそれを悪用する場合、犯罪者が本当にライセンス契約を誤解しただけでなく、攻撃する意図があったことを法廷で証明するのは難しいかもしれませんこれは許可されていると想定しました。難読化された秘密鍵（クライアント自体に含まれる）を使用してクライアントがサーバーで認証される場合、セキュリティの点ではほとんどメリットがありませんが、サーバーを悪用する誰かが偶然にそのキーを取得したことを証明するのは困難であり、意図的なリバースエンジニアリングの取り組みを通じて。
難読化すると、プログラムのリバースエンジニアリングの時間コストが大幅に増加します。おそらく難読化されたプログラムからいくつかの小さな秘密を抽出するのは簡単ですが、そのプログラムの難読化されていないバージョンを作成する作業は、単にそれを書き換えるライバルに匹敵します。新しいアルゴリズムを抽出することは可能ですが、簡単ではありません。
本質的に難読化されたコードは推論できますが、再利用できません。
コードの難読化は、かなりのCS研究のトピックです...難読化が本質的に価値がないであるという公理は、論争になります。
Christian CollbergとNagra Jasvirによる本Surreptitious Software：Obfuscation、Watermarking、and Tamperproofing for Software Protection。をお勧めします。
ソフトウェアの悪用可能なバグが発見されて悪用されると、スキッドキディやランサムウェアではなく、特にあなた（またはソフトウェアを使用している人）をターゲットにしたい、意欲が高く資金が豊富な攻撃者による可能性が高くなります、など.
ほとんどの場合、ソフトウェアのバグはホワイトハットまたはグレイハットの研究者が発見し、2番目の選択肢はskriptキディとランサムウェア、そして最悪のケースなどの州レベルの攻撃者に見つけられると思います。しかし、あなたはその呼び出しを行う必要があります。