問題タブ [binary-reproducibility]

2 つの .NET アセンブリを比較して、それらが「同じ」ソース ファイルからビルドされたかどうかを判断する方法を知っている人はいますか?

Reflector のプラグインなど、いくつかの差分ユーティリティが利用できることは承知していますが、GUI で差分を表示することに興味はありません。同じ (または同等の) ソース ファイル。複数の異なるソース ファイルが同じ IL を生成する可能性があることを理解しており、そのプロセスは元のソースではなく、IL の違いにのみ影響を受けることを認識しています。

2 つのアセンブリのバイト ストリームを比較するだけの主な障害は、.NET にアセンブリに "MVID" (Module Version Identifier) と呼ばれるフィールドが含まれていることです。これは、コンパイルごとに異なる値を持つように見えるため、同じコードを 2 回ビルドすると、アセンブリが異なります。

関連する質問は、コンパイルごとにMVIDを強制的に同じにする方法を知っている人はいますか? これにより、MVID の値の違いに影響されない比較プロセスを使用する必要がなくなります。標準のチェックサムを使用できることを意味するため、一貫した MVID が望ましいでしょう。

この背景には、本番環境へのリリースが許可される前に、サードパーティ企業がリリースを独自にレビューして承認する責任があるということがあります。これには、ソース コードのレビューが含まれます。彼らは、私たちが提供するソース コードが、私たちが以前に構築、テストし、現在展開を計画しているバイナリと一致することを独自に確認したいと考えています。私たちが提供するソースからシステムを独自に構築し、チェックサムをテスト済みのバイナリのチェックサムと比較できるプロセスを探しています。

ところで。継続的インテグレーション、自動ビルド、ソース管理などを使用していることに注意してください。この問題は、特定のビルドにどのソース ファイルが入ったかを内部で制御できないこととは関係ありません。問題は、サード パーティが、サード パーティに提供するソースが、テスト済みで本番環境に入れる予定のバイナリと同じバイナリを生成することを確認する責任があることです。ビルド サーバーやソース コード管理システムを含め、内部システムやコントロールを信頼するべきではありません。彼らが関心を持っているのは、ビルドに関連付けられたソースを取得し、ビルド自体を実行し、出力がデプロイしようとしているものと一致することを確認することだけです。

比較ソリューションの実行速度は特に重要ではありません。

ありがとう

同じコンパイラ/フラグを使用してコンパイルされた 2 つの実行可能ファイルや共有オブジェクトを比較し、それらが変更されていないことを確認する必要があります。私たちは規制された環境で作業しているため、テスト目的で実行可能ファイルのどの部分が変更されたかを正確に特定することは非常に役立ちます。

ファイルに関する情報がヘッダーに含まれているため、MD5Sums/Hashes の使用は機能しません。

2 つのファイルが異なる時間にビルドされた場合でも、実行上同じであることを確認するプログラムまたは方法を知っている人はいますか?

4バイトのデータがあり、セキュリティ操作のために8バイトの配列が必要です。これらの8バイトを4バイトのバイト配列から生成する必要があります。これは再現可能である必要があります。

正確なバイト配列を使用し、4バイトを追加して、既知のシーケンスの初期配列のAND、OR、XOR...で埋めることを考えていました。それが良い考えかどうかはわかりません。この4バイトから8バイトの配列が必要であり、操作は再現可能である必要があります（同じ8バイトと同じ4バイトが与えられます）。C＃で例を挙げてください

こんにちは、ccarm コンパイラを使用して、WinXP で VxWorks 用の C/C++ を開発しています。そして、ずっと前にビルドされたリリースされた配信の上にホットフィックスを追加したいと思います。ソースはクリア ケースに保管され、すべての配送にラベルが付けられます。したがって、特定の配信のソース コードにアクセスすることが可能です。

元のリリース バージョンから何も変更されていないことを確認するために、同じ出力ファイルを再度ビルドできることを確認する必要があります。

ここに問題があります。CC サーバーからソースを取得してビルドします。次に、出力ファイルを対応するリリース出力と比較します (出力ファイルのタイプは *.lad ファイル + ファイル形式 elf32-littlearm です)。そして、その違いは非常に大きいです (一部のタイム スタンプではありません)。一方、アセンブリ リストも比較しましたが、それらも異なります。

何がそのような違いを引き起こすのか、何か考えがありますか? 私の意見では、このような違いを引き起こす可能性のある項目のリスト - リリースされた出力は、自動ビルド スクリプトを使用して別の PC (WinXP) でビルドされました。新しい出力は、同じコンパイラと設定を使用してローカルでビルドされました。-リポジトリから間違ったラベルを取得しました

追加するものはありますか？

前もって感謝します

毎晩自動的にビルドされる共有アセンブリがいくつかあります。ソースに変更が加えられていない場合、アセンブリ バイナリは以前のバージョンとまったく同じであると予想されます。

ただし、アセンブリ間には若干の違いがあるようです。

2 つのビルドの違いを特定するために、いくつかの努力をしました。以前ildasmは il バージョンを生成し、結果のテキスト バージョンを比較しました。(IL での) 唯一の違いは、モジュールの MVID (ランダム GUID) です。

いくつかのグーグルは、モジュールのバージョンIDがコンパイラによって生成されることを教えてくれるので、他のすべてが同じであっても、ビルドソースを特定することができます。

この MVID は、同じコードのビルド間に人為的な差分を作成し、結果のアセンブリの人為的なチェックインを作成します。

MVID を C# コンパイラに提供することは可能ですか?

2つの.exeを比較しようとしていますが、今回はいくつかの変更があります。

• Microsoft VisualStudio2010でプロジェクトを構築する
• プロジェクトターゲットフレームワーク=.NETFramework3.5クライアントプロファイル

プロジェクトをビルドdumpbin /rawdataし、.exeで実行して、テキストファイルに出力します。次に、プロジェクトを再構築dumpbin /rawdataし、新しい.exeで実行して、新しいテキストファイルに出力します。次に、それぞれをCRCして、同じであることを確認します（ビルド間で変更は行われません）。

異なるCRC値を取得しています。生データを実行するとwindiff、セクションに違いが見られますRaw Data #1。これは、プロジェクトのソースコードから生成された実際のデータであると思います（間違っている場合は修正してください）。

には3つの違いがありRaw Data #1、そのうちの1つには.pdbが含まれています。

質問：

1. VS 2010でデバッグ情報をオフにできる場所を知っている人はいますか（Project Property Pages -> Config Properties -> Linker -> Debugging -> Generate Debug InfoVS 2005と同様）
2. WINDIFFで強調表示されている違いが実際にソースコードのどこにあるかを見つけるための秘訣はありますか？

ありがとう、ZayJay

PS-お気軽に説明を求めてください、そしてもう一度トンに感謝します。私はしばらくの間検索しましたが、ほとんど成功しませんでした。このリソースを見つけてよかったです。

編集/更新 私のシフトは、MSILとそこに違いとして現れていたものをバイパスするためにngenでコードをコンパイルすることになりました。違いの1つはこの領域にありました：<PrivateImplementationDetails>{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}.Dictionary...そして私は他の違いのASCIIから何も作ることができません（私は.pdb情報を取り除きました）。

コンパイルされたコードを表示/抽出して表示する方法があるかどうか知りたいのですが。

試しngen display "App Name"に検索しましWINDOWS/assemblyたが、関連するものが見つかりません（また、探しているものが100％わかりません...）

お時間をいただきありがとうございます、ZayJay

ビルド スクリプトを使用して、いくつかの C# プロジェクトをコンパイルしています。バイナリ出力は結果フォルダーにコピーされ、以前のバージョンのファイルが上書きされてから、subversion に追加/コミットされます。

ソースや環境にまったく変更がない場合でも、コンパイルのバイナリ出力が異なることに気付きました。これはどのように可能ですか？バイナリの結果は、同じ入力に対して正確に等しいはずではありませんか?

どこでも特別なタイムスタンプを意図的に使用しているわけではありませんが、コンパイラ (Microsoft、.NET 4.0 に含まれているもの) がタイムスタンプ自体を追加する可能性はありますか?

私が尋ねている理由は、出力を subversion にコミットしているためです。ビルド サーバーの動作方法により、チェックインされた変更が再構築をトリガーし、再度変更されたバイナリ ファイルがサークル内でチェックインされます。

これまでは VS からプロジェクトをコンパイルしていましたが、コンパイル プロセスをスクリプトに移行しました。vcbuild.exeこの目的のために、コマンド ライン パラメータを使用します。私が見ているのは、出力ファイルがバイトごとにまったく似ていないことです。 VS のコマンド ラインとスクリプトのコマンド ラインを比較したところ、最後のコンマまで同じなので、なぜそんなに違うのかわかりません。

VS コンパイルとログのコマンド ラインは同じですvcbuild(わかりやすくするために改行を追加しています)。

ソースの整合性のために、ソースコードをできるだけ変更せずにブースト1.50バイナリを再現可能にすることができるかどうかを確認する必要があります。課題は、.cppまたは.hppファイルを変更せずにそれを行うことです。

単純に2回コンパイルし、diffを実行すると、 BoostライブラリのWAVEおよびSPIRITに表示される__TIME__および__DATE__マクロが原因で失敗が示されます。

g++4.1.1を使用してコンパイルしています。ある種の環境変数を介してこれらのマクロを定義解除または再定義するようにプリプロセッサに指示する方法を知っている人はいますか？env varでない場合は、g ++コマンドラインオプションを使用しますか？.jamファイルを編集して__TIME__と__DATE__ 、マクロを????に再定義できる可能性があると思います。または、gccがデフォルトと言っているのは、それらを解決できない場合です。

おそらく、プリプロセッサが現在の日付と時刻を解決できないようにする方法があります。これを有効にして、ビルドしてから、無効にすることができますか？

これに関するアイデアをいただければ幸いです。ありがとうございました。

編集：これをフォローしている人には、元の質問で重大な間違いを犯したと思います。同じ正確なbjamビルドコマンドを使用した単純な連続ビルドでは、DATEマクロとTIMEマクロだけでなく大幅に異なる.aファイルと.soファイルが生成されることがわかりました。バイナリの16進差分は、.soファイルの違いの大きな塊を示しています。.aファイルは、一貫して異なる同じ値のパターンに従っているようです（これは、TIMEとDATEである可能性が非常に高いです）。マクロ値）が、.soファイルは同じ球場にさえありません。誰かが気分になっている場合は、ブースト1.50を2回ビルドして、ビルド出力を比較し、ビルドの日付/時刻の変更が構成する単なる情報の違い以外に大きな違いがないことを確認してください。

編集（続編！）：さらに多くの掘り下げを行った後、ある種の一貫性のない名前マングリングのように見えるものを発見しました。ブーストファイルシステムを2回、連続して構築し、2つのファイルpath.oの違いを調べると、次のことに気づきました。

第path.oのNM：00000000 Bの_ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_8F1C916311path_localeEの0000000C _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_8F1C916312dot_dot_pathE 00000000 R _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_8F1C916316separator_stringE 00000004 B _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_8F1C91638dot_pathE B _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_8F1C916317codecvt_facet_ptrE 00000004 R _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_8F1C916326preferred_separator_stringE 00000008 B

第path.oのNM：00000000 Bの_ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_EDDD474511path_localeEの0000000C _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_EDDD474512dot_dot_pathE 00000000 R _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_EDDD474516separator_stringE 00000004 B _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_EDDD47458dot_pathE B _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_EDDD474517codecvt_facet_ptrE 00000004 R _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_EDDD474526preferred_separator_stringE 00000008 B

こんなことは今まで見たことがないと思います。これらの特定のローカル変数の定義が、8F1C9163ではなくEDDD4745でマングルされるのはなぜですか？何かご意見は？私の頭は今日すでに一度爆発しました（近くのジャック・オー・ランタンによって解決されました）。これはただ悪質です。

編集：v3）

残念ながら、私はまだそれに取り組んでいます。この時点で、私はELFファイルの仕様レベルで、何が変更されているのかを判断しようとしています。この時点では、ブーストファイルシステムを使用しています。私のbjamコマンドは

何がこれらの違いを引き起こしているのかを判断しようとするのは非常に面倒です。readelfは役に立ちますが、ある程度までです。ここに、同じ正確なソースコードを使用したboostfilesystem.soの2つのビルドでの2つのreadelfコマンドの差分があります。私はこれらのことについてまだ十分な知識がなく、これらの変更に何が影響するかを完全に判断することはできませんが、おそらく世界中の誰かがそうです。

（投稿に収まるように、ファイル内のいくつかのエントリを簡略化する必要がありました）。ほとんどの場合、これらのエントリの一部の行番号が異なるように見えます。ELFファイルのシンボルエントリの順序を変更できる可能性があるのは何ですか？

以下のように単純なソース.csファイルを提供します。MSBuild（または少なくともcsc.exe）を使用して同一の.dllを生成する方法はありますか？そのため、それらのバイナリハッシュは一致しますか？

foo.cs

foo.bat

サンプルのバイナリ差分レポートはhttps://dl.dropbox.com/u/65419748/CscBin.htmlにあります。

誰かがそれらの違いが何であるか、そしてそれらを回避する方法を知っていますか？