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:
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?
mount -t minix -o loop U19.IMA /mnt/cdy obtengo el error genérico pero esto aterriza en dmesgVFS: 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.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.Respuestas:
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:
mountmount with offset, o useddpara extraer una partición con desplazamiento y luego monte esa partición solamente o use algo comokpartxPuede utilizar las utilidades
hexdumpystringspara 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:
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: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: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í:¡Intentar
cpioen primer lugar no puede doler!fuente
cpio. ¡Parece recordar que esto intentó extraer directamente a mi unidad raíz!