Montaje de un antiguo archivo de imagen de disquete (formato .ima): ¿qué tan difícil puede ser?


10

Estoy intentando mountacceder a un archivo de imagen de disquete en formato .ima (volcado sin formato a disquete, similar a .img ) en ArchLinux.

Este archivo es parte de un conjunto de 30. No es de arranque, sino más bien una continuación de un conjunto. El propósito no es la manipulación por el bien de la instalación o la clonación. Estoy interesado en la documentación contenida con otros datos en el disco.

Información del archivo de imagen

Aquí hay información sobre este archivo de imagen:

# file U19.IMA
U19.IMA: PC formatted floppy with no filesystem

# fdisk -lu U19.IMA
Disk U19.IMA: 1.4 MiB, 1474560 bytes, 2880 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

(parted) print
Error: /home/meh/Downloads/U19.IMA: unrecognised disk label
Model: (file)
Disk /home/meh/Downloads/U19.IMA: 1475kB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:

Monte fallar

Aquí está el mensaje de error genérico:

mount -o ro,loop U19.IMA /mnt/cd/
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error

He intentado muchas combinaciones tratando de especificar un tipo con -t, es decir, ntfs, msdos, iso9660, vfat, y siempre obteniendo el mismo error. Pensé que tal vez sea algún tipo de formato de archivo ntfs, pero ntfs-3G no funciona mucho mejor, así que no, no lo es:

# ntfs-3g -o loop U19.IMA /mnt
NTFS signature is missing.
Failed to mount '/home/meh/Downloads/U19.IMA': Invalid argument
The device '/home/meh/Downloads/U19.IMA' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

# ntfsclone -r -o file.img U19.IMA
ntfsclone v2013.1.13 (libntfs-3g)
ERROR: Input file is not an image! (invalid magic)

Alguien sugirió tal vez un Minix fs. Si bien no está claro si realmente puedo montar dicho sistema de archivos con mi configuración actual, intenté:

mount -t minix -o loop U19.IMA /mnt/cd
which gave the generic error but there was this at the bottom of the log:
VFS: Can't find a Minix filesystem V1 | V2 | V3 on device loop0.

Parece que esto no es concluyente, ya que cuando especifique un tipo específico de sistema de archivos tendrá un tipo específico de error en el registro. También probé [fuseiso][2]:

# fuseiso U19.IMA /mnt/cd
init: wrong standard identifier in volume descriptor 0, skipping..
init: wrong standard identifier in volume descriptor 1, skipping..
init: wrong standard identifier in volume descriptor 2, skipping..
init: wrong standard identifier in volume descriptor 3, skipping..
init: wrong standard identifier in volume descriptor 4, skipping..
init: wrong standard identifier in volume descriptor 5, skipping..
init: wrong standard identifier in volume descriptor 6, skipping..
init: wrong standard identifier in volume descriptor 7, skipping..
init: wrong standard identifier in volume descriptor 8, skipping..
init: wrong standard identifier in volume descriptor 9, skipping..
init: wrong standard identifier in volume descriptor 10, skipping..
init: wrong standard identifier in volume descriptor 11, skipping..
init: wrong standard identifier in volume descriptor 12, skipping..
init: wrong standard identifier in volume descriptor 13, skipping..
init: wrong standard identifier in volume descriptor 14, skipping..
init: wrong standard identifier in volume descriptor 15, skipping..
init: wrong standard identifier in volume descriptor 16, skipping..
init: wrong standard identifier in volume descriptor 17, exiting..

Donde puedo ver esas cosas con dmesg:

[ 5316.082629] FAT-fs (loop0): invalid media value (0xf6)
[ 5316.082644] FAT-fs (loop0): Can't find a valid FAT filesystem

Además, lsmod | grep loopda

loop 18511 0

No hay un superbloque alternativo de ningún tipo:

# mkfs -n U19.IMA
mke2fs 1.42.8 (20-Jun-2013)
U19.IMA is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
184 inodes, 1440 blocks
72 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=1572864
1 block group
8192 blocks per group, 8192 fragments per group
184 inodes per group

Al contrario de muchos casos sobre los que leí, parece que no hay necesidad de especificar ningún desplazamiento aquí ya que no hay una partición integrada en la imagen. En tales casos, a veces el ddcomando se usa para transferir el contenido a una imagen similar utilizando un valor de desplazamiento que permite el montaje. Esto parece lo mismo que especificar un desplazamiento al mountcomando directamente. Pero esto debería ser fácil, como en este otro caso donde losetupse usa un simple y luego se monta el dispositivo de bucle. Puedo vincular el archivo .ima con losetup, pero cuando intento montar el dispositivo de bucle termino con mi mensaje de error inicial.

Integridad de los datos

Finalmente, safecopy --stage1no informa ningún problema con los datos y el resultado hasta la etapa 3 sigue siendo el mismo y produce el mismo error:

# safecopy U19.IMA test.img --stage1
Low level device calls enabled mode: 2
Reported hw blocksize: 4096
Reported low level blocksize: 4096
File size: 1474560
Blocksize: 4096
Fault skip blocksize: 147456
Resolution: 147456
Min read attempts: 1
Head moves on read error: 0
Badblocks output: stage1.badblocks
Marker string: BaDbLoCk
Starting block: 0
Source: U19.IMA
Destination: test.img
. ;-} 100%
Done!
Recovered bad blocks: 0
Unrecoverable bad blocks (bytes): 0 (0)
Blocks (bytes) copied: 360 (1474560)

Aquí está la parte superior del archivo y el contenido parece estar intacto:

dd if=U19.IMA | hexdump -C | head -n 10
00000000 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 |................|
*
00004600 34 2e 30 2e 32 20 33 38 36 75 6e 69 78 20 46 6e |4.0.2 386unix Fn|
00004610 64 20 53 65 74 20 35 20 6f 66 20 31 30 0a 00 00 |d Set 5 of 10...|
00004620 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

"Forense"

Dado que una imagen sin procesar consiste en una copia binaria sector por sector del medio fuente, el formato real del contenido del archivo dependerá del sistema de archivos del disco desde el que se creó la imagen (como una versión de FAT). [...] Dado que los archivos IMG no contienen datos adicionales más allá del contenido del disco, estos archivos solo pueden ser manejados por programas que pueden detectar sus sistemas de archivos.

Siguiendo las sugerencias, procedí a analizar algunos de los otros archivos de imagen en el conjunto (30):

fdisk -lu U14.IMA
Disk U14.IMA: 1.4 MiB, 1474560 bytes, 2880 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
This doesn't look like a partition table. Probably you selected the wrong device.

Device Boot Start End Blocks Id System
U14.IMA1   3840       11519      3840       0  Empty
U14.IMA2   2425393152 4850786447 1212696648 0  Empty
U14.IMA3 ? 2425393296 4850786591 1212696648 90 Unknown
U14.IMA4 ? 2425393296 4850786591 1212696648 90 Unknown

Lo sentimos, pero parece una tabla de partición, pero es inusual. Incluye la propiedad id 90 :

90h     MBR, EBR    CHS, LBA    x86, 68000, 8080/Z80    Hidden, Filesystem  FreeDOS     Free FDISK  Hidden FAT16 (corresponds with 04h i.e. MS Fat16 DOS 3.0+ < 65536 sectors)

Entonces, tratando de montar la imagen que obtengo:

# mount -t auto U14.IMA /mnt/cd
mount: unknown filesystem type 'sysv'  <-----

Como alguien insinuó, debe tener algo específico como ' Sistema V y soporte de sistema de archivos coherente ' compilado en el núcleo para usar algo como mount -t sysv. La cadena sysv no es tan sorprendente, ya que esto es parte de los medios de instalación AT&T UNIX System V / 386 Release 4 Versión 2.1, un puerto que fue compatible con Sun hasta 2006 , y estas imágenes terminaron en libertad en 2007. En realidad, un texto El archivo incluido con las imágenes indica que son necesarias para la instalación debido a la naturaleza del sector de arranque y el formato en uso. Hay una indicación de que el material estaba originalmente en Teledisk (TD0) formato. Quiero enfatizar aquí que este no es material original. En cualquier caso, no puedo calcular los desplazamientos como se explica en la pregunta, o bien no termino con enteros al dividir entre 512, e incluso si lo intento parece que no puedo encontrar el desplazamiento adecuado, dd: cannot skip to specified offset, 0 writesetc. en este punto, la respuesta es sobre forense y ya no se trata de un archivo de imagen.

Emulación rápida del sistema operativo de fuente de imagen histórica con qemu

AT&T UNIX System V Release 4 Versión 2.1

                          LABEL             Version         X of X
  AT&T UNIX SVR4.0 2.1 --------------------------------------------------

  U01.IMA                 Maintanace Disk1  2.1             2 of 2
  U02.IMA                 Remote Terminal   2.1             1 of 1
                          Package
  U03.IMA                 BSD Comp. Pkg.    2.1             1 of 2
  U04.IMA                 BSD Comp. Pkg.    2.1             2 of 2
  U05.IMA                 Networking Supp.  2.1             1 of 1
                          Util. Pkg.
  U06.IMA                 Xenix Comp. Pkg   2.1             1 of 1
  U07.IMA                 FACE Pkg.         2.1             1 of 1
  U08.IMA                 FMLI Pkg.         2.1             1 of 1
  U09.IMA                 Editing Utils.    2.1             1 of 1
  U10.IMA                 OA&M Basic & Ext. 2.1             1 of 3
  U11.IMA                 OA&M Basic & Ext. 2.1             2 of 3
  U12.IMA                 OA&M Basic & Ext. 2.1             3 of 3
  U13.IMA                 Foundation Set    2.1             1 of 10
                          Base System Pkg.
                          2 User System
  U14.IMA                 Base              2.1a            1 of 10
  U15.IMA                 Base              2.1             2 of 10
  U16.IMA                 Base              2.1a            2 of 10
  U17.IMA                 Base              2.1             3 of 10
  U18.IMA                 Base              2.1             4 of 10
  U19.IMA                 Base              2.1             5 of 10
  U20.IMA                 Base              2.1             6 of 10
  U21.IMA                 Base              2.1             7 of 10
  U22.IMA                 Base              2.1             8 of 10
  U23.IMA                 Base              2.1             10 of 10
  U24.IMA                 Maintanance 1     2.1             1 of 2
  U25.IMA                 Base              2.1             9 of 10
  U26.IMA                 Printer Pkg       2.1             3 of 3
  U27.IMA                 Printer Pkg       2.1             2 of 3
  U28.IMA                 Printer Pkg       2.1             1 of 3
  U29.IMA                 16 to unlimited   2.1             1 of 1
                          User License
  U30.IMA                 2 to 16 User      2.1             1 of 1
                          License

Como se sugirió, instalé desde una imagen anterior en el conjunto. Implica usar qemu como se explica aquí, básicamente, comenzando con la imagen 14 (primero, losetup /dev/loop0 U14.IMAluego una simple qemu-system-x86_64 -m 256 -hda test.img -fda /dev/loop0 -boot a), ya que U19 no es de arranque. Lo que es bueno aquí es que no tiene que montar / desmontar imágenes en el sistema operativo mismo, solo usa ctrl-alt-2o 1 con qemu para acceder o salir del monitor y usa list blockspara ver qué está montado y change floppy0 imagenameen esa interfaz para cambiar la imagen archivo, es decir, durante la instalación, por ejemplo.

Tuve que suministrar U19.IMA (disco 5) durante la instalación (para un registro textual de la instalación, vea esto , ¡lo más destacado es la referencia a MS-DOS!), Y terminé con esto, es decir, un sistema ATIX de UNIX instalado correctamente V 386 OS, así que esto confirma U19.IMA es una imagen de disco que funciona:

ingrese la descripción de la imagen aquí

Por defecto, / dev / fd está montado en / dev / fd y también hay acceso de disquete a través de un dispositivo de bloque (/ dev / dsk / f0) y sin formato (/ dev / dsk / f0). Cambiar el directorio al disquete solo muestra archivos numerados del 1 al 23 (supongo que es solo la estructura del dispositivo de caracteres). También puede catusar los dispositivos sin formato y bloquear y ver que los datos del disquete están allí, pero eso es lo más cercano posible.

Me he dado cuenta de que en ese sistema operativo, no instalas cosas desde disquetes al iniciar algún script desde un directorio en ellos como lo haces con archivos binarios descomprimidos, por ejemplo, aquí utilizas pkgadd -d diskette1(seguramente esa última palabra es un alias, pero yo Encontré una referencia al modificador -d en el material SCO para pkgadd (1M)y generalmente aparece a menudo en Unix comercial (Oracle, HP share pkgadd (1M)). Al emitir el comando, se inicia una rutina en la que proporciona disquetes y no tiene control, excepto decir "no" después de que la rutina descubre lo que hay en la unidad. En el caso de los discos que comienzan una secuencia de instalación (U03, U05, etc.), se instalará y luego solicitará el siguiente disquete, etc. hasta que se complete la instalación del paquete. Si coloca un disquete que no es el comienzo de un conjunto, básicamente no encuentra nada, pero le dice que tal vez tenga que usar el installpkgcomando.

¿Instalaré una unidad de disquete física en mi equipo para acceder a los datos en ese archivo de imagen?


Solo una suposición: podría ser un sistema de archivos Minix. Probablemente necesite recompilar su kernel para soportarlo. Instalar una unidad de disquete física no ayuda. ¿Qué tan grande es el archivo de imagen? Si su archivo es solo una imagen en bruto, definitivamente no contiene ninguno de los sistemas de archivos (actuales / modernos) que intentó. Parece que no es arrancable en sistemas i386.
jofel

@jofel El archivo es 1475k grande. Si trato de montarlo de esa manera mount -t minix -o loop U19.IMA /mnt/cdy obtengo el error genérico pero esto aterriza en dmesg VFS: Can't find a Minix filesystem V1 | V2 | V3 on device loop0.¿Es alguna indicación de que el núcleo ya lo tiene o no puedo confiar en eso? De todos modos, investigaré lo que dijiste. Sé que no es de arranque, aunque quiero acceder a los contenidos. Gracias.

La salida de filesugiere que no hay un sistema de archivos en la imagen. ¿Estás seguro de que tus datos están realmente allí? Parece que está intentando montar una imagen de una unidad sin formato sin particiones ni sistema de archivos.
terdon

@terdon Esto es exactamente lo que quiero hacer. ¿Es eso un fracaso lógico? Este es un conjunto de instalación. Esperaba encontrar "archivos", incluida la documentación. ¿No puedo acceder a esto fuera de instalar todo?

2
Si se trata de un disco de instalación, podría ser que solo el primer disco contenga un sistema de archivos / sea arrancable. Los otros discos podrían contener solo datos en un formato personalizado sin ninguna sobrecarga del sistema de archivos.
jofel

Respuestas:


4

Si no puede montar la imagen, es posible que en algunos casos pueda "transmitir" algunos de sus datos cpio.

Una vez que haya determinado si la imagen es:

  • Una imagen que utiliza un sistema de archivos compatible y una partición -> mount
  • Una imagen usando un sistema de archivos compatible y más de una partición -> mount with offset, o use ddpara extraer una partición con desplazamiento y luego monte esa partición solamente o use algo comokpartx
  • Una imagen que no utiliza un sistema de archivos compatible o que no tiene ningún sistema de archivos -> soporte de kernel e investigación adicional ...

Puede utilizar las utilidades hexdumpy stringspara intentar analizar el encabezado y extraer cadenas de texto de la imagen y obtener más información sobre el archivo de imagen y su estructura.


Algo captó mi interés en hacerlo:

@(#)/usr/bin/echo.sl 1.1 4.0 10/01/90 16865 AT&T-SF

Hay una línea como esta para cada binario en la imagen, así que de alguna manera sabes qué hay allí. Además, en este caso, cuando observa de cerca cómo ocurre el proceso de instalación en la plataforma original installpkg, descubre que:

El mecanismo básico para transferir software desde un disquete al disco duro del sistema UNIX V / 386 es cpio.

Básicamente, los datos se extraen con cpio/ usr / tmp / install y se incluye una serie de archivos (un archivo de instalación, ascii, archivo, nombre y tamaño). Sucede aquí que este comando:

cat U19.IMA | cpio -imdv

salidas numéricas malformados errores, para empezar, pero luego crea una carpeta / usr / bin con el contenido de la imagen! Lo trque estaba buscando está ahí:

#file tr
tr: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped.

¡Intentar cpioen primer lugar no puede doler!


Solo tenga cuidado con la opción -d y cpio. ¡Parece recordar que esto intentó extraer directamente a mi unidad raíz!
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.