1

そのため、私の雇用主は、書き直す必要があり、ソース コードが失われたこの古い .NET / C# プログラムを持っています。元従業員によって開発されましたが、彼らは何年もここにいません。多分それは彼らの側の見落としだったのかもしれませんし、そうでなかったのかもしれません - 現時点ではそれは本当に問題ではありません.

とにかく、私はそれが何をするのかを理解しようとしています.NET逆コンパイラの制限について考えさせられました.

縮小された js ファイルを読み取り可能にしようとするのと同じように、.NET を逆コンパイルしようとしていますか? 縮小されたjsを使用すると、コードを所定のコーディング標準にインデントでき、変数に値を割り当てる関数の名前と一致するように変数の名前を変更できますが、それでも多くの情報が失われます. 実際の変数名と開発者が行ったコメントが失われます。

それは公正な類推ですか？

それが私の場合に起こっていることであるか、そうでなければ開発者は実際にコメントを残さず、アプリケーションではなくタイプに基づいて変数の半分に名前を付けたようです（これはシステムハンガリーと一致すると思います） .

4

2 に答える 2

2

注: 私が言っていることのほとんどは Java に基づいていますが、私が理解しているように、CLR はほとんど同じように動作します。

基本的には、コンパイラがソース コードをバイトコードと呼ばれる形式に変換し、VM で実行できるようにするという仕組みです。一般に、コンパイラは生成するコードをわざわざ最適化することはありません。これは、実行時に VM によって最適化されるためです。したがって、コードが標準コンパイラによってコンパイルされ、難読化されていない場合、バイトコードへの変換は非常に直接的で予測可能です。つまり、適切な外観のソースに逆コンパイルできます。

ただし、基本的に構文糖衣であるものはすべて失われます。コンパイラは、実行に必要なものだけを含めます。幸いなことに、リフレクションのサポート (および有効な場合はデバッグ) は、おそらくオプションのメタデータを通じて、多くのソース レベルの情報がバイトコードに保存されることを意味します。しかし、空白やコメントなどはリフレクションでもアクセスできないため、それらを回復する方法はありません。

縮小された JS との類似性は正確ではありませんが、それでも有用です。Javascript の場合、ソース ファイルは VM への入力であるため、目に見える中間バイトコード ステージはありません。縮小は、オプティマイザーがソース コードを調べて再フォーマットした結果ですが、それでもソース コードです。一方、どちらの場合も、失われた情報は、ツールが実行に不要であるために保存されなかった結果です。

ファイルが難読化されていた場合、すべてが窓の外に出ます。難読化ツールは、コンパイラによって導入されたパターンを故意に台無しにし、可能な限りすべてのオプションのメタデータを削除します。多くの場合、難読化されたコードを逆コンパイルできますが、それは混乱し、書式や変数名などの元のソースの有用な情報を保持しません。

于 2013-04-10T22:03:29.997 に答える