質問

リフレクションを介してアプリケーションの内部について多くのことを知ることができます。それは.NET BCL(ベースクラスライブラリ)によって公開され、.NETメソッドの実際のILを取得するのは簡単です。

ウィキペディアのリバースエンジニアリング:

  

リバースエンジニアリングは   発見のプロセス   デバイスの技術的原理、   の分析によるオブジェクトまたはシステム   その構造、機能、操作。

反射は、構造の分析として確実に満たされます。しかし、イントロスペクションと実際のリバースエンジニアリングの境界線はどこにありますか?そして、法的観点から、リフレクションはリバースエンジニアリングですか?

役に立ちましたか?

解決

2つの境界線はぼやけているように見えます。倫理的には、プログラマーの動機に線を引きます。

リフレクションを使用して、特定の基準を満たすサードパーティコードとやり取りするはずのライブラリ、ツール、または同様のソフトウェアを構築する場合、リバースエンジニアリングとは見なされません。

たとえば、私は最近、Linq2SQLデータレイヤーの一般的な基本クラスを書いていました。基本クラスはリフレクションを使用して、データベースレイアウトの洞察を得て、ネストされたビジネスエンティティの更新を適切に処理します。他の誰かが彼のWebアプリケーションに私の基底クラスを使用している場合、私は彼のソースコードに関する知識を得ることはできません。反射のこの使用法は、確かにリバースエンジニアリングではありません。

一方で、プログラマがリフレクションを使用して競合他社のソフトウェアによる内部動作を理解しようとする場合、彼はそれをリバースエンジニアリングしています。

他のヒント

言語を簡単に逆コンパイルする機能が言語ala Reflectionの一部である場合、リバースエンジニアリングの定義を疑問視する必要があります。

.NET Reflector のようなツールを使用すると、実際に行が始まるように感じますぼかし!

SO自体の例を使用して、最近ソースコードの難読化を解除 WMDエディター。これは、リフレクションが行うよりもリバースエンジニアリングを定義していると主張します。

Reflectionは、アセンブリから情報を読み取るための単なるツールであるため、それ自体はリバースエンジニアリングされません。

この情報を使用してアセンブリがどのように作成されたかを調べる場合、たとえば.NETリフレクターを使用して、同じILコードを生成できる読み取り可能なソースコードを生成する、つまりリバースエンジニアリングです。

Reflectionは単なるツールです。リフレクションの使用は、必ずしもリバースエンジニアリングを意味するわけではありません。

たとえば、リフレクションを使用して、リバースエンジニアリングを意味しないアセンブリ内のすべてのパブリックメソッドおよび保護されたメソッドのシグネチャを検出する場合。

法的観点からは、リバースエンジニアリングの定義を見つけるには、懸念している法律を調べる必要があることをお勧めします。

Reflectionは、コードのリバースエンジニアリングを含む多くのことに使用できるツールです。リフレクションは他の多くの目的にも使用できます。たとえば、リフレクションのおかげで動的言語の実装がはるかに簡単になります。

反射だけでは、リバースエンジニアリングには不十分です。その方法でプログラム構造に関する情報を見つけることができますが、コードを逆コンパイルする必要があります。リフレクターのようなツールはこの機能を追加します。

実際には、リバースエンジニアリングの正反対です。

適切に、「リバースエンジニアリング」プロセスの結果を確認し、逆戻りして、そこに到達した方法を判断することです。一般に、元のコードの知識がなくても実行され、通常は非常に異なるプロセスが生成されます。

著作権者による恐ろしい脅威にもかかわらず、それは完全に合法です。

"解体" (別名" Reflection")は、ハードディスク上のバイトを読み取り、それらに意味を割り当てるだけのアクションです。これはまさに、CPUがコードを実行するときに行うことです。ここでは、人間が読めるようにしています。繰り返しますが、著作権者による恐ろしい脅威にもかかわらず、それは完全に合法です。

他人のコードを販売する(または自分で使用する)ことは、著作権者が自分の作品から利益を得ることを避ける方法で、 違法ですが、それについてはここでは話しません。

ここで2つの異なることについて話していると思います:

  • Reflection はテクニックであり、リバースエンジニアリング(特に)に使用できます。
  • リバースエンジニアリングは、目標を達成するためにリフレクションを使用できるアクションですが、必ずしもそうする必要はありません。

リバースエンジニアリングの目的でリフレクションを使用している場合、法的な観点からは、目標によって異なります。

もちろんIANALですが、リバースエンジニアリング自体は違法ではないと思います。それは、プロキシによる違法な活動になる可能性があります。つまり、著作権の侵害などにより

いいえ。リフレクションでは、通常、メソッドを呼び出す別の方法について話しているか、メソッドの属性を見ているだけです。

対照的に、リバースエンジニアリングの製品は、著者のアルゴリズムとアイデアを理解するために見ることができるソースコードを生成することを期待しています。これは通常、彼らが保護しようとしているものです。

弁護士に法的質問をする必要があります。弁護士はお金を請求します。弁護士を雇わないことは、弁護士に尋ねないことで訴えられた場合、さらに費用がかかる可能性があります。

最善策:尋ねる必要はありません。 Microsoftはすでに多くの.NETのソースをリリースしています。 http://www.microsoft.com/resources/sharedsource/default.mspx

それはすべて、あなたが熟考する範囲に依存します。 Reflector のようなツールを使用する場合、またはそのようなコードを自分でコーディングする場合は、実際にソースコードにアクセスしているので、リバースエンジニアリングになります。

Reflectionは、Donが言ったようにメソッドを呼び出したり属性を調べたりするために使用できますが、アセンブリの構造を分析したり、基礎となるMSILコードを覗き込んだりするためにも使用できます。したがって、リフレクションの1つの使用は無害であり、1つはリバースエンジニアリングです。

Reflection は、数十年前に使用されていた一般的なコンピューターサイエンス用語です。 Microsoft .Netフレームワークの導入(SUN JVMより)。このアイデアは、アプリケーションのリバースエンジニアリングを目的としたものではありませんでした 。特定のコンテキストでは、この目的に使用できることは偶然です。他の人が書いているように、リフレクションは「ツール」です。

.NETやJavaなどの多くの言語でのリフレクションは、オブジェクトと自由にやり取りすることを許可しない、貧弱な構文のパッチです。

SmalltakやSelfなどの実際のオブジェクト指向言語では、リフレクションはほとんど必要ありません。必要に応じて、.NETやJavaが提供する言語よりもはるかに強力です。

とはいえ、REは他の保護を破るのではなくコードを理解してコードを理解することに似ていると考えると、リフレクションはリバースエンジニアリングだと思います。

現在、Drupal(PHPベース)で多くの作業を行っています.Drupalは、モジュールの名前を定義済みのフック名に連結してその関数が存在するかどうかを確認するなど、見苦しいものを使用します(たとえば、module_hook_name)。

非常に便利ですが、メッセージに答えることができる抽象クラスをサブクラス化することで回避できる実際のオブジェクト指向言語を信じており、サブクラスはそれをオーバーライドできます。

プログラミング言語の欠陥が見られる極端な状況を除いて、反射は使用しないでください。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top