コンパイル済みでサポートされなくなった ASP.NET Web サイトに変更が必要な小さなプロジェクトを完成させました。コードは醜いものでしたが、コンパイルする前でさえ醜いものでした。
生成されたファイルに挿入され、逆コンパイルされた基本クラスと競合するため、コントロール宣言を削除するなど、いくつかの編集が必要でしたが、数時間で修正されたものはありませんでした。
今、私は他の何人がこれをやってどれだけ成功したかについて興味があります. リバース エンジニアリング プロセスの定義 (自動化ではないにしても) について、CodeProject の記事を書きたいと思っています。
Will: .NET プラットフォームに存在するすべてのコンパイラ シュガーのおかげで
幸いなことに、この特定のアプリケーションは信じられないほど単純でしたが、元のコードに逆コンパイルすることは期待していません。元のコードと同じように機能するだけでなく、新しいコードの「スプライシング」を可能にするために、元の機能についての洞察を提供することさえできます。 .
私は似たようなことをしなければなりませんでしたが、コードを持っていた場合よりも実際に幸せでした. 時間がかからなかったかもしれませんが、コンパイラーが最適化した後のコードの品質は、おそらく元のコードよりも優れていました。そうです、単純なアプリケーションであれば、リバース エンジニアリングを行うのは比較的簡単です。一方、私は将来そうする必要がないようにしたいと思います。
.NET プラットフォームにはさまざまなコンパイラ シュガーが存在するため、バイナリを元のコードに逆コンパイルするには、非常に高度な逆コンパイラが必要です。たとえば、コンパイラはエンクロージャを処理するためにバックグラウンドでクラスを作成します。この種のことを自動化するのは大変な作業のように思えます。ただし、コンパイルするためだけに予想される問題を処理することは、スクリプト化できる場合があります。
.NET 1.1 または .NET 2.0 で作成された場合、VS 2008 コンパイラでコンパイルされたものよりもはるかに多くの成功を収めることができます。これは主に、新しい言語のリビジョン (Lambda、匿名クラスなど) によってもたらされた構文上の問題のためです。 .
コードが難読化されていない限り、リフレクターを使用して実行可能なコードを取得できるはずです。その後、それをVSに配置すると、リフレクトされたコードのエラーをすぐに見つけることができます。
で始まる変数/メソッドに注意してください<>、私はそれをたくさん見ます（特に.NET 3.5を反映するとき）。
最悪の場合は、すべてを VS にエクスポートし、コンパイルして、エラーの数を特定し、そこから呼び出しを行うことです。
しかし、それが十分に単純なプロジェクトである場合は、リフレクターからリバース エンジニアリングを行い、少なくともリフレクターを使用してコードが行っていることの一般的な要点を取得し、自分自身を再コーディングできるはずです。