He creado varios archivos DMG desde la misma carpeta. ¿La suma de comprobación es diferente en cada uno?

Hace bastante tiempo me di cuenta de que incluso si creo archivos DMG desde el mismo directorio, con los mismos archivos, etc., los resultados siempre son diferentes. No solo su tamaño es ~15 bytes más corto/más largo entre sí, sino que sus sumas de verificación SHA (y sus contenidos, cuando se ven desde el editor HEX) difieren drásticamente. Solo por curiosidad, he creado 5 archivos DMG comprimidos sin cifrar de la misma carpeta que contiene nada más que un solo archivo de texto. Los resultados son:

  • 0.dmg | tamaño - 26 204 bytes, suma de comprobación - 5ba9ba0ee4d8ec5ba4718f1b491baf31c2c4e642
  • 1.dmg | tamaño - 26 221 bytes, suma de comprobación - a86d76f6c07ee5a81c0aefb31b6fd40ef787ebd5
  • 2.dmg | tamaño - 26 235 bytes, suma de comprobación - a31f4cf29e4e2858b7ac63c82574499200d81108
  • 3.dmg | tamaño - 26 209 bytes, suma de comprobación - f3c19414279b6d6b94b90341453906e4a69e28dd
  • 4.dmg | tamaño - 26 217 bytes, suma de comprobación - 9603c0334125762fc7908343e3ee400e038fe779

He estado navegando por Internet con la esperanza de encontrar algo sobre el "aleatorizador de datos en APFS", pero... obviamente no pude encontrar nada y, además, no mucha gente sabía sobre esta "característica". ¿Hay alguna información al respecto?

Estoy ejecutando macOS 10.12.6, los archivos DMG se crearon con Disk Utility, pero obtengo los mismos resultados con hdiutil.

Necesitamos más información para dar una respuesta adecuada. Sin embargo, sospecho que la fuente en realidad está cambiando, aunque solo sea en los metadatos (marcas de tiempo de acceso, etc.), y que el DMG refleja estos cambios. ¿Ha intentado probar con diferentes sistemas de archivos en el contenedor?
Si los bytes cambiaron, los datos cambiaron, lo que significa que la suma de verificación cambiará. Sospecho que jsejcksn tiene razón y se están cambiando los metadatos (15 bytes es muy pequeño). Intente comprimir los datos primero, luego cree dmg de eso y vea si los datos y las sumas de verificación permanecen iguales, o proteja el directorio antes de crear el dmg.
Configuré el sistema de archivos en RW y creé 2 archivos DMG, y uno de ellos es 40 bytes más grande que el segundo. Tal vez tenga razón, y los metadatos de ese archivo de texto cambien ("¿se abrió por última vez", tal vez?). Intentaré escribir un script simple que generará la información del archivo y, con suerte, aparecerá algún resultado útil.
También bloquearé el archivo, como sugirió Christian.
Muy bien, entonces es el tiempo de acceso el que cambiaba constantemente. Lo arreglé desactivando el "atime" en los demonios de lanzamiento, pero apareció el nuevo problema: a pesar de que los metadatos son prácticamente iguales (las estadísticas son idénticas ahora), los archivos DMG siguen siendo diferentes. Que puede ser esto...
@ L0W_P1X3L: tendría que examinar la estructura detallada de la imagen del disco para encontrar qué cambió. Esto será mucho más fácil si no está comprimido. Pero, en general, no debe esperar que los mismos archivos generen exactamente la misma imagen de disco: el formato de imagen de disco puede incluir (o depender de) mucha información extraña que probablemente sea muy difícil de controlar. No estoy seguro de por qué desea obtener la misma imagen de disco varias veces, pero cualquiera que sea su objetivo real, debe encontrar una forma diferente de lograrlo.

Respuestas (1)

Las copias de uno existente dmgserán idénticas, pero dmglos archivos creados por separado no lo serán.

Efectivamente garantizado para diferir

El formato de imagen de disco de Apple .dmg garantiza efectivamente que no habrá dos imágenes de disco idénticas bit a bit. La igualdad entre imágenes de disco que contienen el mismo contenido no es un requisito práctico del formato.

UUID dentro del bloque 0x6B6F6C79/koly

Dentro del dmgformato de archivo se encuentra la kolyestructura . Esta estructura incluye un SegmentID de tipo uuid_t. Este es un identificador único universal ( UUID ) de 128 bits. El identificador SegmentID por sí solo garantizará que cada dmgarchivo difiera en más de un bit.

El uso de HFSleuth en la imagen de disco de iTunes 11.0 muestra el UUID incrustado:

HFSleuth> ver
Verbose output is on
HFSleuth> fs iTunes11.dmg
KOLY header found at 200363895:
    UDIF version 4, Header Size: 512
    Flags:1
    Rsrc fork: None
    Data fork: from 0, spanning 200307220 bytes
    XML plist: from 200307220, spanning 56675 bytes (to 200363895)
    Segment #: 1, Count: 1
    Segment UUID: 626f726e-7743259b-6086eb93-4b42fb65
    Running Data fork offset 0
    Sectors: 1022244

En el ejemplo anterior, la línea Segment UUID: 626f726e-7743259b-6086eb93-4b42fb65es un identificador único universal incrustado en la imagen del disco.

Diferencias de un bit y funciones hash

Una diferencia en un bit debería dar como resultado un cambio del 50 % o más en la salida de una función hash criptográfica, como SHA-2.

El uso de un UUID dentro de la estructura no es para garantizar que cada imagen de disco sea única, sino para facilitar la identificación de segmentos dentro de la imagen de disco. Que un UUID proporcione propiedades únicas más allá del alcance de la imagen del disco es un subproducto del uso del UUID.