C ++アプリケーションコードを難読化することは重要ですか？
Javaの世界では、時々問題となるようですが、C++についてはどうですか？異なる解決策はありますか？
私は誰かが特定のOSのC++ライブラリを同じライブラリの異なるバージョンで置き換えることができるという事実を考えていましたが、私のコードが何をするかを理解するためのデバッグシンボルでいっぱいです。 IS tt標準または一般的なライブラリを使用するのは良いことですか？
これは、Windowsの一部のdllライブラリがそのライブラリの「デバッグバージョン」に置き換えられた場合にも発生する可能性があります。静的コンパイルを優先する方が良いですか？商用アプリケーションでは、アプリのコアとしてすべてを静的にコンパイルし、ほとんどの場合dll（ダイナミックライブラリ一般）を使用して、海賊版対策などのサードパーティのテクノロジーを提供しています（多くのゲームでこれを確認しています） ）、GUIライブラリ（Qtなど）、OSライブラリなど.
静的コンパイルは、Java=世界の難読化に相当しますか？より正確に言えば、コードを保護するための最良かつ最も手頃なソリューションですか？
負けた戦いに時間を無駄にしないでください
C++および他の言語に関する他の多くの同様の回答で述べられているように、これはほとんど役に立たないです。
参考文献
トピックの選択された読み取り（すべてがC++固有ではありませんが、一般原則が適用されます）：
StackExchange Answers
- コード難読化のケース？
- リリースコードを難読化する利点は何ですか？
- 逆コンパイラ-神話か事実か
- JSコードを暗号化して、誰かがコピーするのを難しくすることはできますか？
- C/C++コードを難読化しますか？ （C++難読化ツールの場合、本当に必要な場合...）
論文
- Code（De）Obfuscation（Madou、Anckaert、De Bosschere）
- バイナリ難読化のソースコード変換の有効性について（Madou＆al。）
- ソースコード難読化の有効性：実験的評価（Ceccato＆al。、2009）[ [〜＃〜] pdf [〜 ＃〜] ]
- 難読化の品質と難読化手法（Witkowska、2006）
難読化に関する有名な引用：
そして最後に、コードのプライバシーの問題があります。これは失われた原因です。熱心なハッカーがプログラムを理解するのを妨げるような変化はありません。これは、すべての言語のすべてのプログラムに当てはまりますが、JavaScriptの場合はソース形式で提供されるため、JavaScriptの場合はさらに当てはまります。難読化によって提供されるプライバシー上の利点は幻想です。プログラムを他の人に見られたくない場合は、サーバーのプラグを抜いてください。 - Douglas Crockford
決して？
決して難読化してはならず、そのための正当な理由はないと言っているわけではありませんが、ほとんどの場合、その必要性とその費用対効果に真剣に疑問を投げかけています。
さらに、難読化が事実上の要件である状況もあります。たとえば、ウイルスを作成する場合、明らかに難読化（および動的なもの）は、複製する能力と同じくらいプログラムの存続にとって良いことです。ただし、これは「一般的な」ケースを構成することはほとんどありません...
いいえ、これは努力する価値はありません。私はそれは完全に不必要だと思います。呼び出す関数は、おそらく提供する機能によって推測できます。
難読化ツールがJavaに存在する理由は、JavaバイトコードとJavaソースコード間のマッピングがかなり明確に定義されており、すべての関数とメンバー変数の名前がパブリック、プライベート、または保護されているかどうかに関係なく、バイトコードに格納されるため、Javaバイトコードインタープリターは、元のソースの構造を示すいくつかの一般的なJavaを提示できます。難読化されていないソースにはかなり良い。
C++は直接機械語にコンパイルされます。逆アセンブルすることはできますが、アセンブリ言語を扱うのはかなり退屈です。コンパイル中にオプティマイザがコードに対して行うすべての変更のため、逆コンパイルはよりトリッキーです。
これを考えると、難読化にはいくつかの異なるタイプがあります。まず、ソースコードの難読化から始めましょう。これは時間の浪費です。それなしでは理解するのは難しいです！そこで、代わりに、配信パッケージの難読化、ユーザーへのコードの配信方法に焦点を当てましょう。
マイナー難読化
ちょっとした難読化は、カジュアルなユーザーが指を突っ込んだり、物を簡単に壊したりするのを防ぐために存在します。それは決定的なハッカーを締め出すことはありませんが、あなたにサポートを求められているものがあなたが実際に提供したものであることを保証するのを助けるのに価値があります。この種のものに必要な保護のレベルは非常に低いです。配信パッケージは単にlookを読み取りおよび編集可能（専門ツールなし）にする必要はなく、それで十分です。
Javascriptの縮小化はこの例ですが、そのように販売されていません。十分に決定された/永続的である場合、技術的には可能ですが、縮小されたJSファイルを読み取って編集することを望んでいる人はいないでしょう。
同様にJavaアプリケーションを配信します。コードを実行可能なJARにパッケージ化するだけで、愚かさの大部分が停止します。都市公園。
C++コードを配信する場合でも、実行可能ファイルから不要なシンボルを削除するだけで、軽微な難読化と見なすことができます。重要なのは、結果をユーザーとして読み取るのはawkwardですが、コンピューターとして実行するのに問題はないということです。
主な難読化
主要な難読化により、決定されたおよび知識のあるユーザーが除外されています。また、完全に負けたゲームでもあります。コンピュータがそれを実行できる場合、人はそれをバラバラにして、それが何をするかを理解することができます。あなたが得ることができる最も近いのは、プログラムを継続的に復号化させて、一度にそれが行うことを、別の時にそれを行う完全に異なるものに変換することです。そのようなものを作成することはかなり困難であり、それでも本当に優れたハッカーを締め出すことはできません（ただし、すべての自己変更コードを解読するために必要な労力で、最終的には完全にハッカーと交差します）。
他のソリューションの観点から考える方がはるかに優れています。たとえば、制御するサーバーにコードの「宝石」を保持し、コードへのサービス呼び出しのみを許可することで、クライアントを本質的に無料のプレゼントとして、貴重なビットのフロントエンドにすることができます。または、より契約/法的手段を講じて、実行可能ファイルを正式にコード内をいじらないことに同意する組織に引き渡すか、そうする場合は補償することもできます（そのため、ある種のNDAになります）。目的は、ハッカーがハッキングしないように強力なインセンティブを作成し、ユーザーが契約に拘束されないハッカーからコードを遠ざけることです。
ただし、コードがクラックされることは決してないと想定してはなりません。仮想化を使用すると、実行のあらゆるプログラム状態を検査および追跡でき、それを無効にしようとするもの（たとえば、外部のタイムソースへのクロック追跡）は、ハッカーよりも正当なユーザーに問題を引き起こす可能性がはるかに高くなります。 （どのように非常に決定された情報の発行者が、コードが敵の手に渡った後もシステムを安全に保つことができないかについては、DRMの履歴を参照してください。 ）実際に合法的なユーザーを幸せにすることに集中する方がはるかに良いです。時折の亀裂による損失は、顧客を適切に満足させることによってもたらされる余分なお金に比べれば何もないでしょう。