Determine si los ensamblados .NET se crearon desde la misma fuente

Question

¿Alguien sabe de una manera de comparar dos ensamblados .NET para determinar si se crearon a partir de los "mismos" archivos fuente?

Soy consciente de que hay algunas utilidades de diferenciación disponibles, como el complemento para Reflector, pero no estoy interesado en ver las diferencias en una GUI, solo quiero una forma automática de comparar una colección de binarios para ver si se construyeron a partir de los mismos (o equivalentes) archivos fuente. Entiendo que múltiples archivos de origen diferentes podrían producir el mismo IL, y me doy cuenta de que el proceso solo sería sensible a las diferencias en el IL, no a la fuente original.

El principal obstáculo para simplemente comparar las secuencias de bytes para los dos ensamblajes es que .NET incluye un campo denominado "MVID" (Module Version Identifier) ​​en el ensamblaje. Esto parece tener un valor diferente para cada compilación, por lo que si construye el mismo código dos veces, el ensamblado será diferente.

Una pregunta relacionada es, ¿alguien sabe cómo forzar que el MVID sea el mismo para cada compilación? Esto evitaría que necesitáramos tener un proceso de comparación que no sea sensible a las diferencias en el valor del MVID. Sería preferible un MVID consistente, ya que esto significa que se podrían usar sumas de verificación estándar.

El trasfondo de esto es que una empresa externa es responsable de revisar y firmar independientemente nuestras publicaciones, antes de que se nos permita lanzar a producción. Esto incluye revisar el código fuente. Quieren confirmar de forma independiente que el código fuente que les proporcionamos coincide con los binarios que construimos, probamos y planeamos implementar. Estamos buscando un proceso que les permita construir el sistema de forma independiente desde la fuente que les proporcionamos, y comparar las sumas de comprobación con las sumas de comprobación de los binarios que hemos probado.

BTW. Tenga en cuenta que estamos usando integración continua, compilaciones automáticas, control de fuente, etc. El problema no está relacionado con una falta de control interno sobre qué archivos de origen se incluyeron en una compilación determinada. El problema es que un tercero es responsable de verificar que la fuente que les proporcionamos produce los mismos binarios que hemos probado y planeamos poner en producción. No deberían confiar en ninguno de nuestros sistemas o controles internos, incluido el servidor de compilación o el sistema de control de código fuente. Lo único que les importa es obtener la fuente asociada con la construcción, realizar la construcción ellos mismos y verificar que los resultados coincidan con lo que decimos que estamos implementando.

La velocidad de ejecución de la solución de comparación no es particularmente importante.

gracias

Answer 1

Hay algunas maneras de hacer esto dependiendo de la cantidad de trabajo que usted está dispuesto a hacer y la importancia del desempeño y/o exactitud. Una forma en que señaló Eric J. es comparar los ensamblajes en binario, excluyendo las partes que cambian en cada compilación. Esta solución es fácil y rápida, pero podría darle muchos falsos negativos. Una mejor forma es profundizar utilizando la reflexión. Si el rendimiento es crítico, puede comenzar comparando los tipos y, si coinciden, vaya a las definiciones de los miembros. Después de verificar las definiciones de tipo y miembro y si todo es igual a ese punto, puede ir más allá al examinar el IL real de cada método al obtenerlo a través del método GetILAsByteArray. Nuevamente encontrará diferencias incluso si todo es lo mismo pero compilado con banderas un poco diferentes o una versión diferente del compilador. Diría que la mejor solución es usar una herramienta de integración continua que etiquete la compilación con el número de conjunto de cambios de su control de origen (está utilizando uno, ¿no?).

A related article

Answer 2

No es demasiado doloroso para utilizar las herramientas de línea de comandos para filtrar EIMV y sellos de fecha y hora a partir de una representación de texto de la IL. Supongamos que file1.exe y file2.exe se crean desde las mismas fuentes:

c: \ temp> ildasm/all/text file1.exe | find/v "Sello de fecha y hora:" | find/v "MVID"> archivo1.txt

c: \ temp> ildasm/todo/texto file2.exe | find/v "Sello de fecha y hora:" | find/v "EIMV"> file2.txt

c: \ temp> fc file1.txt file2.txt

Comparación de archivos file1.txt y FILE2.TXT

FC: no hay diferencias encontradas

Answer 3

Otra solución a tener en cuenta:

La información del código fuente se almacena cuando los binarios se compilan en modo de depuración. Luego puede verificar si pdb coincide con exe y si las líneas de pdb coinciden con el código fuente.

Answer 4

He utilizado la solución de Jerry Currry en .Net 4 ensamblados y descubrí que ahora hay un tercer elemento que variará en cada compilación: Checksum. ¿No es sorprendente encontrar una suma de comprobación dentro de un conjunto? Creo que la adición de la suma de comprobación de un archivo dentro de ese archivo cambiará la suma de comprobación ...

De todos modos, el comando modificado es:

ildasm /all /text "assembly.dll" 
| find /v "// Time-date stamp:" 
| find /v "// MVID:" 
| find /v "// Checksum:" 
> assembly.dasm 

Tenga en cuenta que también he cambiado las cadenas de búsqueda un poco añadiendo las barras, para evitar coincidencias involuntarias. Las líneas de este comando se deben ejecutar juntas en la misma línea, dividir para la legibilidad. Los nombres de archivo necesitarán comillas dobles a su alrededor si contienen espacios.

Answer 5

puede usar MonoCecil y darle una pequeña modificación para resolver el problema. Lo hice, se puede leer cómo aquí: http://groups.google.com/group/mono-cecil/browse_thread/thread/6ab42df05daa3a/49e8b3b279850f13#49e8b3b279850f13

Saludos Florian

Answer 6

Al comparar bibliotecas de clases con ILDASM v4.0.319.1, parece que la base de la imagen no se ha inicializado. Para evitar desajustes, utilizar una solución revisado:

ildasm /all /text assembly.dll 
| find /v "// Time-date stamp:" 
| find /v "// MVID:" 
| find /v "// Checksum:" 
| find /v "// Image base:" 
> assembly.dasm 

Punto de entrada (base de imagen) es en realidad la información interesante para los conjuntos ejecutables, y tendrá que ser verificada con cuidado. Inyectar una nueva base de imágenes es una forma común de hacer que un programa haga algo completamente diferente. En mi caso, estoy tratando de verificar la consistencia de compilaciones multiproceso, por lo que es seguro saltear el punto de entrada.

Una nota sobre el rendimiento: Tomé una DLL de 8MB que se creó para AnyCPU y ejecuté ILDasm. El archivo resultante tenía un tamaño de 251 MB y tardó varios minutos en hacerlo. Aproximadamente 32 veces el tamaño fue producido.

Answer 7

Puede usar el Reflector Diff AddIn here.