問題タブ [disassembly]

次のアセンブラー出力リストを検討してください。

1. コードの前の + 記号は何を意味しますか?
2. のアドレスが ONE指定されているのはなぜ001ですか?
3. RESULT DS 1最後のステートメントの後のエントリが空白になっているのはなぜですか?

このリストは、 Dhamdhere によるSystems Programming and Operating Systemsに掲載されています (編集者注: 回答者によって発見されたとおり)。

非常に古い MSDos ベースのペイント プログラムがいくつかあります。これらは、パレット インデックス付きのイメージ バッファで動作します。それらには、現代のどのペイント プログラムにも存在しない、数多くの見事な形状描画ツール、ブラシ、および効果があります。dosbox のようなエミュレーターを起動しなくても、これらの素晴らしいツールの多くを最新のプログラムで再現したいと考えています。しかし、私には問題があります。

これらのブラシやツールなどの多くには明らかな機能がありますが、その実装はかなり簡単です。しかし、他のツールでは、その操作の原則はそれほど明白ではありません。それらを実装するための正しいまたは忠実なアルゴリズムを決定するのに行き詰まります。

あなたが私だったら、どのようなアプローチをとりますか？このような古いプログラムを処理できる逆コンパイラ/逆アセンブラはすぐに利用できますか? それとも、さまざまな入力でアルゴリズムを体系的にテストして、基になる関数を推測するなど、別のアプローチを採用しますか? さまざまなテクニックの組み合わせ？これらのプログラムの 1 つの行の場合、これらの (商用) プログラムの元の作成者はわかっており、現在では熱狂的なオープン ソースの支持者です。直接連絡して聞いてみるしかないでしょうか？私はリバース エンジニアリングの経験が特にないので、どこから始めればよいか途方に暮れています。

編集：「尋ねると受け取る」は本当にうまくいくようです。

編集 2:ソースを入手したプログラムのソース コードについては、http ://animatorpro.org を参照してください。デラックス ペイントもいいですが、ダン シルバは地球上から姿を消したようです。

.net JITer によって生成されたマシン コードの逆アセンブリを確認するにはどうすればよいですか? [逆アセンブル ウィンドウを表示] メニュー オプションはどこにもありません。そのためのツールバー ボタンも無効な状態です。私の記憶が正しければ、分解は実際に見ることができますが、何らかのトリックに頼る必要があります。残念ながら、そのトリックが何であったかは覚えていません。誰かがここでいくつかの指針を提供してもらえますか?

デバッグ環境: VS2008 (WinDbg と一部のデバッガー拡張機能 (SOS.dll?) で問題なく逆アセンブリを確認できると思います) うーん、VS2008 でも同じ dll が使用されている可能性があると思います。確認して折り返しご連絡いたします。間違っていたら遠慮なく訂正してください。）

特定の Windows 実行可能ファイルまたは DLL をビルドするために使用された C または C++ コンパイラを特定するにはどうすればよいでしょうか? 一部のコンパイラは、最終的な実行可能ファイルにバージョン文字列を残しますが、これは Linux よりも Windows ではまれなようです。

具体的には、Visual C++ とさまざまな MinGW コンパイラ (通常は関数シグネチャからかなり簡単) を区別し、次に Visual C++ バージョン (6、2002/2003、2005、2008; より難しい) を区別することに興味があります。半信頼できる方法で区別できるツールはありますか?

DLL ライブラリ内の関数を呼び出す VB6 アプリケーションを逆アセンブルしましたが、逆アセンブルで DLL への参照が見つかりません。呼び出し元のコードは、この DLL をどのようにロードできますか? DLL の削除と置換の影響を観察できるため、動的にリンクされています。

IDA Pro Free を使用しています。呼び出し元のアプリケーションは VB6 アプリで、DLL はプレーンな Win32 DLL で、C または C++ を使用して作成されたと思われます。

C ++プログラムのアセンブリコードを確認するにはどうすればよいですか？

これを行うための人気のあるツールは何ですか？

x86 コードをある種のオブジェクト モデルに逆アセンブルし、コードを分析するルーチンを作成するために使用できるライブラリを探しています。x86 コードをテキスト逆アセンブリに変換するライブラリには興味がありません。それらのライブラリはいくつか見つかりましたが、逆アセンブルしたコードの上で何らかの作業を行いたいので、あまり役に立ちません。 . ああ、それを .Net コードにしたいと思います (VB または C# が望ましい)。

Reflectorを使用してプロジェクトをデバッグするために逆アセンブルしましたが、自動プロパティの「コンパイル結果」のデコードに失敗しているようです。たとえば、次の行で構文エラーが発生します。これらを手動で修正しようとしましたが、修正するたびに、さらに表示されます。

これについて私にできることはありますか？

教育プロジェクトとしてx86ディスセンブラーを作成することに興味があります。

私が見つけた唯一の実際のリソースは、SpiralSpaceの「逆​​アセンブラの書き方」です。これにより、逆アセンブラのさまざまなコンポーネントの概要がわかりやすくなりますが、より詳細なリソースに興味があります。NASMのソースコードもざっと見てきましたが、これは学ぶのにやや重いものです。

このプロジェクトの主要な課題の1つは、処理しなければならないかなり大きなx86命令セットであることを認識しています。基本的な構造、基本的な逆アセンブラリンクなどにも興味があります。

x86逆アセンブラの作成に関する詳細なリソースを教えてもらえますか？

私は .NET については多少初心者ですが、プログラミングについては初心者ではありません。また、コンパイル済みの .NET コードを逆アセンブルすることについての傾向と興奮にやや戸惑っています。無意味に思えます。

.NET の高度な使いやすさが、私が .NET を使用する理由です。リソースが限られている環境で、C および実際の (ハードウェア プロセッサ) アセンブリを作成しました。それが、効率のために非常に多くの細心の注意を払うことに労力を費やす理由でした. .NET の世界では、実装の最も不可解な詳細を掘り下げて時間を無駄にすると、高レベルのオブジェクト指向言語を使用するという目的が無効になります。.NET を使用する過程で、通常のパフォーマンスの問題と奇妙な競合状態をデバッグしました。コンパイラが生成している中間言語について考えたことは一度もありませんでした。たとえば、 foreach() が列挙型を使用することを考えると、 for(;;) ループが配列の foreach() よりも高速になることは明らかです。変数を単純にインクリメントするのではなく、次に進むたびにメソッド呼び出しを使用してオブジェクトを作成します。これは、タイトなループを数百万回実行することで簡単に証明できます (逆アセンブルは不要です)。

IL の逆アセンブルを馬鹿げているのは、実際のマシン コードではないという事実です。仮想マシンコードです。実際に命令を移動して最適化するのが好きな人もいると聞きました。私をからかってるの？ジャストインタイムでコンパイルされた仮想マシン コードは、ネイティブにコンパイルされたコードの速度では単純なタイトな for(;;) ループを実行することさえできません。プロセッサから最後のサイクルをすべて絞り出したい場合は、C/C++ を使用して、実際のアセンブリの学習に時間を費やしてください。そうすれば、多くの低レベルの詳細を理解するのに費やす時間は、実際には価値があります。

では、時間に追われる以外に、人々はなぜ .NET (CLR) バイナリを逆アセンブルするのでしょうか?