リフレクションを通じてアプリケーションの内部について多くのことを知ることができます。これは .NET BCL (基本クラス ライブラリ) によって公開され、任意の .NET メソッドの実際の IL を簡単に取得できます。
ウィキペディアのリバース エンジニアリング:
リバース エンジニアリングとは、デバイス、オブジェクト、またはシステムの構造、機能、動作の分析を通じて、その技術原理を発見するプロセスです。
リフレクションは、構造の分析として確かに満足できるでしょう。しかし、内省と実際のリバース エンジニアリングの境界線はどこにあるのでしょうか? 法的な観点からすると、リフレクションはリバース エンジニアリングですか?
2つの間の境界はぼやけているように見えます。倫理的には、プログラマーのモチベーションに線を引きます。
彼がリフレクションを使用して、特定の基準を満たすサードパーティのコードと相互作用することになっているライブラリ、ツール、または同様のソフトウェアを構築している場合、私はそれをリバースエンジニアリングとは見なしません。
たとえば、私は最近、Linq2SQLデータレイヤーの汎用基本クラスを作成していました。基本クラスは、リフレクションを使用してデータベースレイアウトを洞察し、ネストされたビジネスエンティティの更新を適切に処理します。他の誰かが私の基本クラスを彼のWebアプリケーションに使用している場合、私は彼のソースコードについての知識を得ることができません。このリフレクションの使用法は、確かにリバースエンジニアリングではありません。
一方、プログラマーがリフレクションを使用して競合他社のソフトウェアの内部動作を理解しようとしている場合、彼はそれをリバースエンジニアリングしています。
言語を簡単に逆コンパイルする機能がReflectionの言語の一部である場合、リバースエンジニアリングの定義に疑問を投げかける必要があります。
.NET Reflectorのようなツールを使用すると、線が本当にぼやけ始めたように感じます。
SO自体の例を使用して、最近、WMDエディターのソースコードの難読化を解除しました。これは、リフレクションよりもリバースエンジニアリングを定義していると私は主張します。
リフレクションは、アセンブリから情報を読み取るための単なるツールであるため、それ自体はリバース エンジニアリングではありません。
次に、この情報を使用して、たとえば .NET リフレクターを使用して、同じ IL コードを生成できる読み取り可能なソース コードを生成するなど、アセンブリがどのように作成されたかを調べる場合、これはリバース エンジニアリングです。
リフレクションは単なるツールだと思います。リフレクションの使用は、必ずしもリバースエンジニアリングを意味するわけではありません。
たとえば、リフレクションを使用して、リバースエンジニアリングを意味しないアセンブリ内のすべてのパブリックメソッドと保護されたメソッドのシグネチャを検出する場合。
法的な観点からは、リバースエンジニアリングの定義を見つけるために、心配している法則を検討する必要があることをお勧めします。
リフレクションは、コードのリバースエンジニアリングを含む多くのことに使用できるツールです。リフレクションは他の多くの目的にも使用できます。たとえば、リフレクションのおかげで動的言語の実装がはるかに簡単になります。
リバースエンジニアリングには、反射だけでは不十分です。この方法でプログラム構造に関する情報を見つけることができますが、それでもコードを逆コンパイルする必要があります。リフレクターのようなツールはこの機能を追加します。
実際、これはリバースエンジニアリングの正反対です。
適切には、「リバースエンジニアリング」とは、プロセスの結果を確認し、逆方向に作業して、プロセスがどのようにそこに到達したかを判断することです。一般に、元のコードの知識がなくても実行され、通常、非常に異なるプロセスが生成されます。
著作権者による恐ろしい脅威にもかかわらず、それは完全に合法です。
「分解」（別名「反射」）は、ハードディスク上のバイトを読み取り、それらに意味を割り当てるだけのアクションです。これはまさに、CPUがコードを実行するときに行うことです。ここでは、人間が読める形式にしています。繰り返しますが、著作権所有者による恐ろしい脅威にもかかわらず、それは完全に合法です。
著作権者が自分の作品から利益を得るのを回避する方法で他人のコードを販売する（または自分で使用する）ことは違法ですが、ここではそのことについて話していません。
ここでは、次の 2 つの異なることについて話していると思います。
法的な観点からは、リバース エンジニアリングの目的でリフレクションを使用しているかどうかは、目的によって異なります。
もちろん IANAL ですが、リバース エンジニアリング自体は違法ではないと考えています。代理人による違法行為、つまり著作権の侵害などになる可能性があります。
リフレクションは、Microsoft .Netフレームワーク（SUN JVMよりも）が導入される数十年前に使用されていた一般的なコンピューターサイエンス用語です。このアイデアは、エンジニアリングアプリケーションをリバースエンジニアリングすることを目的としたものではありません。特定の状況では、この目的に使用できるのは偶然です。他の人が書いているように、リフレクションは「ツール」です。
それはすべて、あなたが反省する程度に依存します。Reflectorのようなツールを使用する場合、またはそのようなものを自分でコーディングする場合は、実際にソースコードにアクセスするため、リバースエンジニアリングになります。
リフレクションは、Donが言ったように、メソッドを呼び出したり、属性を調べたりするために使用できますが、アセンブリの構造を分析したり、基になるMSILコードの内部を覗いたりするためにも使用できます。したがって、リフレクションの1つの使用は無害であり、もう1つはリバースエンジニアリングです。
いいえ。リフレクションでは、通常、メソッドを呼び出す別の方法について話しているだけです。あるいは、メソッドの属性を調べているだけかもしれません。
対照的に、リバースエンジニアリングの製品は、作成者のアルゴリズムとアイデアを理解するために見ることができるソースコードを生成することを期待しています。これは、通常、作成者が保護しようとしているものです。
法的な質問は弁護士に尋ねなければなりません。弁護士はお金を請求します。弁護士を雇わないことは、弁護士に依頼しないことで訴えられた場合、さらに多くの費用がかかる可能性があります。
最善の策：尋ねる必要はありません。Microsoftはすでに多くの.NETのソースをリリースしています。http://www.microsoft.com/resources/sharedsource/default.mspxを参照してください。
.NETやJavaなどの多くの言語でのリフレクションは、オブジェクトと自由に対話できない構文の悪いパッチです。
SmalltakやSelfのような実際のオブジェクト指向言語では、リフレクションはほとんど必要ありません。必要に応じて、 .NETやJavaが提供する言語よりもはるかに強力です。
そうは言っても、REは他の人の保護を破るのではなく、コードを理解して何かを行うことに似ていることを考えると、リフレクションはリバースエンジニアリングだと思います。
私は現在、Drupal（PHPベース）で多くの作業を行っています。Drupalは、モジュールの名前を事前定義されたフック名に連結して、その関数が存在するかどうかを確認するなど、醜いものを使用して、後で呼び出すことができるようにします（例：module_hook_name）。
これは非常に便利ですが、メッセージに応答できる抽象クラスをサブクラス化することで回避できる実際のオブジェクト指向言語を信じており、サブクラスはそれをオーバーライドできます。
プログラミング言語の欠陥が見られる極端な状況を除いて、Reflectionは使用しないでください。